Перебирая всевозможные комбинации слов в гугле нашёл первичные ответы на свои же вопросы:
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 предоставляет варианты использования бизнес логики в контексте данного приложения? „
Естественно все выводы не подкреплены большим опытом, так как всё было получено в спешных эксперементах.
Поэтому жду критику, обсуждения и размышления.
