Comments 12
Ой-ёй. Диаграмма направления зависимостей неверная. Бизнес логика и UI компоненты не могут зависеть от инфраструктуры. Слой инфраструктуры должен распологаться на одном уровне с UI компонентами.
По теме - единый доменный язык это, наверное, главное что нужно брать из DDD. Остальное - детали имплементации.
Еще поддомены и ограниченные контексты. А остальное, да, детали.
Инфраструктурный слой предоставляет общие технические возможности, поддерживающие более высокие уровни, у Эванса это может быть например обмен сообщениями в приложении, хранение данных для домена, утилиты UI.
Хороший пример библиотеки инфраструктурного уровня на мой взгляд, это различные реактивные расширения, например RxJS
Если ваша бизнес-логика зависит от RxJS (или, например, MediatR, Rx.NET), то у вас, скорее всего, проблемы с архитектурой приложения. Простыми словами - ваших БА интересует какая там версия у Rx.NET новая вышла и надо ли ее обновить, или стори они пишут под RxJS “BehaviorSubject ‘user’ should return current user”? Зависимости на инфраструктуру для бизнес-слоя нужно разворачивать через интерфейсы, чтобы инфраструктура имплементила domain интерфейсы.
Я конечно понимаю, что это отсылка к луковой архитектуре, но всегда есть хотя бы одно но.
Так-то если развить эту идею - у всех бизнес логика зависит от такой инфраструктуры как .net framework или Java.core или что там из модного и современного.
Вообще нет, если упороться, то бизнес логика вообще не зависит от фреймворка)
Так как раз-таки сама суть луковой/гексагональной/чистой (выбрать нужное) архитектуры состоит в том, чтобы бизнес-логика не зависела от инфраструктурного слоя. Без всяких но.
Согласен, даже просто язык программирования может рассматриваться как один из инфраструктурных элементов в разработке программного обеспечения.
Использование фреймворков в доменном слое нарушает SRP принцип. У доменной модели становится два актора. И тогда доменная модель зависит не только от бизнес логики, но еще и от фреймворка. Как пример - JPA в Java (использование аннотаций в бизнес модели). Когда структура бизнес модели зависит еще и от структуры таблиц в базе данных.
Как раз выделил необходимость обособления слоя бизнес-логики. При концептуальной независимости доменного слоя, реальная реализация всегда строится на какой-нибудь инфраструктуре (подсистеме), это как минимум язык программирования, при необходимости также добавляют стандартные библиотеки и расширения языка.
Как DDD работает для меня