В DDD: домен решает, когда сохранять данные?
Но я сомневаюсь, что если модель предметной области должна выполнять только бизнес-логику, почему она должна загружать данные из базы данных и сохранять обновления в базе данных?
Он не загружает данные и не сохраняет обновления. Он говорит кому-то еще (т. е. репозиторию) загрузить данные и сохранить обновления.
Не путайте выполнение работы с инструктированием кого-то другого для выполнения работы, потому что они сильно различаются, когда вы рассматриваете обязанности класса.
В конце концов, именно репозиторий решает, как загружать данные и как их сохранять. Единственное, что делает домен (кроме бизнес-логики), — это подключается к репозиторию.
Таким образом, потребитель (пользовательский интерфейс или пользователь) может решать, сохранять ли данные, использовать службу или выполнять работу только в том экземпляре домена, который у него есть локально.
Имейте в виду, что вы задаете вопрос о дизайне, ориентированном на предметную область. Здесь все решает домен. Он не выполняет рутинную работу (для этого и предназначен репозиторий), но делает последний вызов в отношении того, получает ли репозиторий указание что-то сделать или нет.
Я предполагаю, что более гибко иметь домен, чтобы выполнять только работу домена и возлагать на другого ответственность за сохранение данных.
Если вы сделаете это, вы фактически понизите домен. Теперь это больше не большой босс, командующий выстрелами, потому что «другой» теперь говорит домену выполнить определенную работу, а не позволяет домену определять работу, которую необходимо выполнить.
Суть DDD заключается в том, что Домен является главным начальником логики, а другие уровни существуют в основном для того, чтобы брать на себя бремя второстепенных задач (таких как персистентность или сопоставление), так что Домен может сосредоточиться исключительно на самой бизнес-логике. Речь идет о делегировании: домен вызывает игру, а окружающие слои ее выполняют. Это гарантирует, что логика предметной области останется максимально простой, удобочитаемой и удобной для изменений.
Неспособность легко адаптировать или настроить базовую бизнес-логику является очень распространенной причиной того, что программные приложения переходят на очень сложную, медленную и/или дорогостоящую фазу обслуживания. DDD пытается избежать этого, насколько это возможно, сохраняя логику домена легкой и не отвлекаясь на детали технической реализации, такие как, к какому серверу БД подключаться или как сопоставляться с DTO.
Прикрепляю к посту несколько видео по теме: