Comments 17
Если объединить 2 ограниченных контекста, то получится ограниченный контекст. И может быть так и лучше.
В результате, нет ни четких критериев ни функции полезности, которую надо максимизировать. Вкусовщина.
Мне как математику больно на это смотреть
Тут видимо при обследовании нужно делить как разделились экспертные группы для обсуждения, считая что они уже сгруппировались по интересам и понятному им языку. Социальная инженерия. То есть разделение вероятно будет неточным и так потом и останется
Ну а переделать это вообще болезненный процесс. То есть объяснение всему будет "так исторически сложилось"
Если LLM долго пытать засунув иголки под ногти то получается такой набор объективных измеримых критериев. Но неизмеримых, видимо, больше.
1. Lead Time for Change (LT)
Что считаем: календарное время от «взяли в работу» (In Progress) до «в проде». Если нарезали не правильно, то будет много лишних обсуждений и согласований
2. Cost per Change (CC)
Что считаем: прямые человеко-часы + инфра, затраченные на одну фичу/фикc. Чем больше API, coordination, миграций и непопадания в компетенции аналитики и разработки тем он выше.
3. Cross-Context Change Rate (XCR)
Что считаем: долю задач, в которых пришлось менять больше одного контекста/сервиса. Причины очевидны
Более простой пример на мой взгляд - метрика (берите любую), характеризующая меру связности между контекстами и когезивности внутри контекстов.
Пробовал
Получил примеры когда это портит понимание экспертом предметной области. Нужно, чтобы эксперт полностью понимал что происходит
Если фактическая связность не соответствует контекст маппингам из модели, значит - либо модель плохая (двойка эксперту - такое часто происходит, и часто это нормально для плохо исследованных предметных областей; исправляется итеративной переработкой), либо запрогали плохо под хорошую модель (сплошь и рядом) - в том числе социальный фактор (конвей) играет важную роль тут.
В любом случае, эту метрику нужно оптимизировать. Она косвенно влияет на все три, приведённые вами в сообщении: если цельная функция (цельное множество агрегатов) распилена на разные контексты, то связность между этими контекстами повышается, как и вероятность, что прилетит багфикс или импрувмент на эту единую функцию (и, выходит, сразу на несколько этих контекстов).
"Ресурсная модель" в DDD - это скорее нестрогая комплексная методология подхода к моделированию и проектированию. Так как case-by-case адаптация подхода может измениться, нет смысла искать конкретику: всегда встречается что-то частично заимствованное, дополненное, смешанное с другими подходами.
Аналогично любому другому большому фреймворку. Взять, например, TOGAF - по факту этот фреймворк является аналогичной нестрогой методологией, который никто и никогда (за исключением двух компаний) не применяет целиком "от" и "до" по книжке. Да и смысла в этом особо нет, так как стандарт абстрактный и требует приземления на реалии конкретной компании (то, что называется "tailoring").
Как уже тут обсуждалось, DDD - это сказочное существо, которое мало кто видел вживую. Но абсолютно точно, что применение хотя бы каких то принципов из DDD, не обязательно всех, это уже отличный шаг, эволюция, как заметил автор.
Такой код гораздо понятнее, чем:
И написали в качестве плохого примера ... плохой код. DDD вообще ни при чем
var d = Calc(1);
o.StateId = 1;
Вот такой код противопоставляется (или предлагается исправлять) DDD
В чем отличие такого DDD от LD (Linked Data)? LD также формализует предметные области, включая ЕА, бизнес-процессы и родословные.
Такое впечатление, что все прочитали начало идеологии DDD про словарь терминов и ограниченный контекст, а дальше ничего нет?
Боже мой, а что там? Расскажи, что же мы пропустили
Понятия не имею. Но если там только это - обидно. Похоже на введение в большую теорию. А оказывается уже конец фильма.
Из важного в самом DDD ещё есть
Агрегаты и сущности (Aggregates, Entities)
Объекты-значения (Value Objects)
События предметной области (Domain Events)
Стратегии интеграции ограниченных контекстов (Bounded Context Integration)
Но я бы рекомендовал не автора DDD а Скотта Влашина. Тут выжимка.
Коротко о содержании:
1. Введение в DDD и функциональное программирование.
2. Моделирование предметной области через типы (алгебраические типы данных, discriminated unions, record types).
3. Использование неизменяемых данных и чистых функций вместо изменяемых объектов и методов.
4. Явное моделирование ошибок и состояний через типы (Result, Option).
5. Разделение чистой бизнес-логики и побочных эффектов (IO, базы данных).
6. Композиция функций для построения сложных сценариев.
7. Практические примеры и пошаговая реализация реального приложения.
Основная идея книги:
Использовать строгую типизацию и функциональные подходы, чтобы сделать модель предметной области максимально ясной, безопасной и выразительной
Неа. Инструментом аналитика в DDD является не глоссарий, а Event Storming. Результатом процесса будут те самые контексты и глоссарий.
Domain-Driven Design: зачем он нужен аналитику и как его применять на практике