Правильно спроектировать агрегатный корень

Question

У меня есть некоторые проблемы при разработке агрегатного корня. Вот как я это вижу в уме:)

Store (the aggregate root)
-> Sales - A store create a sale every day
 -> Zones - A store is divided into zones
    -> Styles - A zone has x number of styles
       --> Colors - A style has x number of colors
    etc..

Теперь, исходя из этого, мой совокупный корень будет хранилищем. Однако, если бы я сейчас создал для этого репозиторий, выглядело бы это примерно так?

public class StoreRepository()
{
  Store GetById() {...}
  StoreZone GetZone() {...}
  List<StoreZoneStyle> GetStylesByZone() {...}
  List<Color> GetColorsByStyle() {...}
}

Это хороший способ продолжить? Излишне говорить, что я новичок в DDD.

Answer 1

Я думаю, вам нужно рассматривать совокупные границы и сущности как нечто большее, чем просто иерархию. Скорее всего, у вас будет более богатая модель, чем эта.

Первый способ определить, является ли ваш агрегат правильным, состоит в том, что вы можете посмотреть на каждую из сущностей в нем и спросить: «Нужно ли к этому напрямую обращаться?» Если вы ответите «да», то эта сущность, вероятно, не является частью совокупности.

Не зная больше о вашем домене, я могу предположить, что Store действительно является совокупностью. Продажи, с другой стороны, являются более сложными. Да, продажи происходят в магазине, но нужно ли вам использовать продажи самостоятельно? Если они вам нужны вне рамок простой работы с магазином, вероятно, Sales находится за пределами этой совокупности.

Я представляю, что стили и цвета являются неизменяемыми и воспроизводимыми, поэтому в этом случае они, вероятно, будут объектами значений. Зоны уникальны для магазина или различаются?

Лично я нахожу ценность в идентификации всех элементов в домене на бумаге (или доске). Я пройду фазу открытия с заинтересованными сторонами и просто выведу их туда. Затем используйте эти слова в качестве лидеров в разговоре, пытаясь понять, как они связаны. Если вы достаточно хорошо опросите заинтересованную сторону, описание, которое он / она даст, фактически определит большую часть того, что вы ищете.

Не бить мертвую лошадь, но книгу Эванса определенно стоит почитать / прочитать. Это немного сухо, но очень проницательно. Для быстрого начала работы вы можете прочитать бесплатную книгу на InfoQ, которая в основном является кратким изложением книги Эванса.

Answer 2

Совокупные корни являются границами согласованности для транзакций, распределений и параллелизма ( Эрик Эванс через Гойко Адзича ).

Когда два человека изменяют разные Зоны в одном Магазине, должно ли это вызвать конфликт параллелизма? Если нет, то, возможно, Зоны должны быть их собственным Совокупным Корнем отдельно от Магазинов.

Answer 3

Кажется, что «Store» не является агрегатным корнем, потому что вы не хотите скрывать всю функциональность для «Zones», «Sales» и т. Д. За объектом «Store». Таким образом, объект «Store» может быть очень раздутым.

«Магазин», «Зона» и «Продажа» могут иметь свой собственный репозиторий.