Группа связанных агрегатов внутри ограниченного контекста

Question

В образце проекта из красной книги Вона Вернона https://github.com/VaughnVernon/IDDD_Samples он организовал проект следующим образом:

• Bounded Context (1)
  ---- " Слои »или« Гексагональные области »(1.1)
  -------- Группа связанных агрегатов (1.1.1)
  ---------- - Агрегаты и связанные сущности и объекты значений
  -------- Другая группа связанных агрегатов (1.1.1)
  ----------- Агрегаты и связанные сущности и объекты значений
  

Например:

• iddd_agilepm (1)
  ---- application (1.1)
  - ----- ...
  ------- домен (1.1)
  ---------- ...
  --------- - продукт (1.1.1)
  ------------- совокупность продуктов и связанные сущности и объекты значений
  ---------- --- выпуск
  ---------------- выпуска агрегированных и связанных сущностей и объектов значений
  ------------- спринт
  ---------------- Агрегат спринта и связанные сущности и объекты значений
  ------ ------- backlogitem
  ---------------- backlogitem агрегат и связанные сущности и объекты значений
  ---------- .. .
  ----- порты / адаптеры (1.1)
  -------- ...
  
• iddd_collaboration
  

Есть ли формальное определение для «группы связанных агрегатов» внутри ограниченного контекста?

Answer 1

Есть ли формальное определение для «группы связанных агрегатов» внутри ограниченного контекста?

Нет . Не существует стандартизованного языка, который описывает группу связанных агрегатов, меньшую, чем «ограниченный контекст».

Ближайший язык, который я видел, - это использование Уди Даханом «автономного компонента»; его пример был чем-то вроде контекста продаж, где у вас могла быть одна бизнес-политика для ваших небольших клиентов и совершенно другая политика для ваших крупных «премиальных» клиентов. Таким образом, мы обслуживаем одни и те же бизнес-возможности, но с использованием разных реализаций для обеспечения этой возможности. примерно, но не совсем совпадение.