Comments 8
Лучше поздние книги
Domain Modelling Made Functional
И становится понятно, что при событийной модели без entities можно почти обойтись. Заменив на комбинацию чистых функций и неизменяемых данных (records c событиями)
DDD как в книжке непрактичен, но элементы DDD вполне себе востребованы когда команда перестает вывозить когнитивную сложность. Не надо все переписывать, можно начать с островков- доменов, и постепенно отрефакторить кодовую базу.
По какому критерию вы оцениваете достижение оптимальной границы контекста?
Тут только качественно можно оценить: контекст не должен дублировать логику из другого контекста; он должен быть автономен, то есть команда развивающая его не должна зависеть от других команд; ну и минимально возможное число внешних зависимостей, интеграций
Спасибо за ответ, не вполне согласен. Часто команда на репозиторий одна, они могут нарушить первые два критерия даже не заметив. Так как контекст это инкапсуляция знаний домена, то нарушение границы видно в интерфейсах - запрос внешних знаний, или отдача внутренних. В обоих случаях количество нарушений должно быть равно количеству связей между доменами, которые были выявлены на этапе бизнес анализа или сторминга. А проверить "чистоту" домена легко анализатором кода - кросс-доменных имортов быть не должно.
И вместо того, чтобы говорить, например: "Реализуйте мне фичу по расчету экономических показателей", начинает требовать — реализовать микросервис (!) по расчету экономических показателей
Нормальный бизнес обсудит с БА новые функциональные требования, и точно не использует терминологию студентов пьющих пиво на лавочке. Функционал не равно фиче. Первое это слова из запаса зрелых специалистов, второе из разговора двух разработчиков интерфейсов.
Самая большая сложность "продать" подход бизнесу. :'-(
Забыли упомянуть важный момент: subdomain discovery (problem space) vs bounded context design (solution space).
Domain-Driven Design: ошибки, которые не описаны в книгах