Пытаюсь уже несколько месяцев осознать философию DDD и у меня не получается :)
Сейчас у меня есть 5 слоёв — infrastructure, domain, application, data access layer ,web.
Есть реализация паттернов UnitOfWork, Repository, Specification в Data Access Layer. Их интерфейсы в инфраструктуре.
1. И вот собственно вопрос, где мне выбирать и сохранять данные, в каком слое?
2. Должен ли слой Domain знать о интерфейсе репозитория/единицы работы?
3. Должна ли вся логика использования DAL (UoW, repository ...) находится в слое Application?
4. Где должны находится условия выборки данных (specification)?
5. Если требуется записать какое либо значение в БД во время выполнения бизнес логики (вызов 1 метода из слоя Domain, при этом значение для записи существует между началом и концом выполнения метода, но не до и не после), то как осуществить такую запись в БД?
Не исключаю что я привожу пример какой-то конкретной архитектуры, которую я считаю де-факто для DDD.Но судя по всем этим умным книжкам, именно такие слои и должны существовать в DDD приложении.
Читал книги, смотрел много кода на github, посмотрел много ответов на stackoverflow, но в моём коде ничего так и не связывается.
Поэтому решил открыть вопрос для более открытого общения. Спасибо за внимание.
Ибо ответ так и не найден, продолжу монолог.
Ещё одним хорошим решением было хранить интерфейсы для репозиториев.
В этих интерфейсах должны быть такие методы как GetLastUser, GetRockMusic()… На основе паттернов Repository и Specification б такие методы будут содержать 1-2 строчки реализации, что очень и очень удобно. И полезно при оптимизации запросов.
Спустя какое-то время как я задал вопрос, мне выпола возможность почитать больше книг и статей.
Сейчас же когда я читаю свои же вопросы, начинаю понимать их размытость, иногда некорректность.
Так что, если вы дорогой читать задаётесь теме же вопросами, просто копайте более глобально, обязательно найдёте другую дорожку.
А лучше найдите DDD-практика и учитесь у него :)
Перебирая всевозможные комбинации слов в гугле нашёл первичные ответы на свои же вопросы:
1. Все манипуляции с БД делаем с помощью Repository/UnitOfWork в слое Application.
2. Нет. Ибо Persistence Ignorance
3. Да.
4. Тут можно выделить 2 вида спецификаций — Бизнес и БД. Спецификации бизнес логики храним в Domain слое. Так же есть спецификации для определённых ORM / БД, но сейчас не могу найти конкретный пример.
5. Бизнес логика должна быть спроектирована так, что бы не возникало подобных ситуаций. Но если всё таки нужно, то можно реализовать
Domain Events. Создаём внутри домена, подписываемся на них в слое Application, и «поджигаем» во время выполнения какого-то бизнес процесса.
И Domain ничего не знает про логгеры/бд/etc и задача выполняется.
Из минусов можно считать непредвиденные для бизнес логики ошибки во время выполнения обработчиков события. Но и тут я думаю можно избавится от проблемы на уровне Application слоя.
И всё же остаются вопросы как выбирать данные из БД во время выполнения бизнес процесса. Здесь всё становится проще, если понимать и использовать Aggregation Root.
Звучит всё достаточно хорошо, но теперь вытекает следующий вопрос что такое Application layer, что он делает, а что не делает?
Правильно ли выражение «Application layer предоставляет варианты использования бизнес логики в контексте данного приложения? „
Естественно все выводы не подкреплены большим опытом, так как всё было получено в спешных эксперементах.
Поэтому жду критику, обсуждения и размышления.
Прошло более трех лет.. Наверняка, у вас уже сформировался неплохой опыт по DDD. Не могли бы вы сейчас попробовать что то прояснить новичкам?
Что же всё-таки должны содержать/не содержать слои:
- Application
- Domain
- Infrastructure
