Domain-Driven Design: ошибки, которые не описаны в книгах

[Dhwtj]

Лучше поздние книги

Domain Modelling Made Functional

И становится понятно, что при событийной модели без entities можно почти обойтись. Заменив на комбинацию чистых функций и неизменяемых данных (records c событиями)

[Alew]

Не лучше, попытка натягивать ФП на все что движется ничем не отличается от аналогичной попытки с ООП

[olku]

DDD как в книжке непрактичен, но элементы DDD вполне себе востребованы когда команда перестает вывозить когнитивную сложность. Не надо все переписывать, можно начать с островков- доменов, и постепенно отрефакторить кодовую базу.

По какому критерию вы оцениваете достижение оптимальной границы контекста?

[avkazakov]

Тут только качественно можно оценить: контекст не должен дублировать логику из другого контекста; он должен быть автономен, то есть команда развивающая его не должна зависеть от других команд; ну и минимально возможное число внешних зависимостей, интеграций

[olku]

Спасибо за ответ, не вполне согласен. Часто команда на репозиторий одна, они могут нарушить первые два критерия даже не заметив. Так как контекст это инкапсуляция знаний домена, то нарушение границы видно в интерфейсах - запрос внешних знаний, или отдача внутренних. В обоих случаях количество нарушений должно быть равно количеству связей между доменами, которые были выявлены на этапе бизнес анализа или сторминга. А проверить "чистоту" домена легко анализатором кода - кросс-доменных имортов быть не должно.

[avkazakov]

Интересная метрика, в таком ключе не задумывался над этим. Спасибо!

[olku]

Не за что. Помогаю внедрять DDD Lite, так вот заказчики заразы за одну лишь теорию Эванса и список лучших практик платить не желают. Им конкретику подавай "сколько вешать в граммах". :)

[Zulu0]

И вместо того, чтобы говорить, например: "Реализуйте мне фичу по расчету экономических показателей", начинает требовать — реализовать микросервис (!) по расчету экономических показателей

Нормальный бизнес обсудит с БА новые функциональные требования, и точно не использует терминологию студентов пьющих пиво на лавочке. Функционал не равно фиче. Первое это слова из запаса зрелых специалистов, второе из разговора двух разработчиков интерфейсов.

[zooh]

А feature flag, например - это из какого словарного запаса?

[Zulu0]

https://habr.com/ru/articles/543420/

Судя по контексту это точно не бизнес термин. Мы же обсуждаем архитектуру со стороны бизнеса?

[zooh]

А почему не бизнес? Термин feature начали применять к продуктам задолго до появления компьютеров.

https://en.m.wikipedia.org/wiki/Software_feature

[Zulu0]

Это самый низкий уровень. На примере оператора связи: фича - опция подключаемая к тарифу абонента (допустим, дополнительные 5Gb трафика). В рамках крупных ограниченных контекстов оно сложно применимо... и опять у меня вопросы к архитектуре...

[voroninp]

Самая большая сложность "продать" подход бизнесу. :'-(

Забыли упомянуть важный момент: subdomain discovery (problem space) vs bounded context design (solution space).