Если фактическая связность не соответствует контекст маппингам из модели, значит - либо модель плохая (двойка эксперту - такое часто происходит, и часто это нормально для плохо исследованных предметных областей; исправляется итеративной переработкой), либо запрогали плохо под хорошую модель (сплошь и рядом) - в том числе социальный фактор (конвей) играет важную роль тут.
В любом случае, эту метрику нужно оптимизировать. Она косвенно влияет на все три, приведённые вами в сообщении: если цельная функция (цельное множество агрегатов) распилена на разные контексты, то связность между этими контекстами повышается, как и вероятность, что прилетит багфикс или импрувмент на эту единую функцию (и, выходит, сразу на несколько этих контекстов).
"Ресурсная модель" в DDD - это скорее нестрогая комплексная методология подхода к моделированию и проектированию. Так как case-by-case адаптация подхода может измениться, нет смысла искать конкретику: всегда встречается что-то частично заимствованное, дополненное, смешанное с другими подходами.
Аналогично любому другому большому фреймворку. Взять, например, TOGAF - по факту этот фреймворк является аналогичной нестрогой методологией, который никто и никогда (за исключением двух компаний) не применяет целиком "от" и "до" по книжке. Да и смысла в этом особо нет, так как стандарт абстрактный и требует приземления на реалии конкретной компании (то, что называется "tailoring").
Если фактическая связность не соответствует контекст маппингам из модели, значит - либо модель плохая (двойка эксперту - такое часто происходит, и часто это нормально для плохо исследованных предметных областей; исправляется итеративной переработкой), либо запрогали плохо под хорошую модель (сплошь и рядом) - в том числе социальный фактор (конвей) играет важную роль тут.
В любом случае, эту метрику нужно оптимизировать. Она косвенно влияет на все три, приведённые вами в сообщении: если цельная функция (цельное множество агрегатов) распилена на разные контексты, то связность между этими контекстами повышается, как и вероятность, что прилетит багфикс или импрувмент на эту единую функцию (и, выходит, сразу на несколько этих контекстов).
Более простой пример на мой взгляд - метрика (берите любую), характеризующая меру связности между контекстами и когезивности внутри контекстов.
"Ресурсная модель" в DDD - это скорее нестрогая комплексная методология подхода к моделированию и проектированию. Так как case-by-case адаптация подхода может измениться, нет смысла искать конкретику: всегда встречается что-то частично заимствованное, дополненное, смешанное с другими подходами.
Аналогично любому другому большому фреймворку. Взять, например, TOGAF - по факту этот фреймворк является аналогичной нестрогой методологией, который никто и никогда (за исключением двух компаний) не применяет целиком "от" и "до" по книжке. Да и смысла в этом особо нет, так как стандарт абстрактный и требует приземления на реалии конкретной компании (то, что называется "tailoring").