DDD Совокупный корневой дизайн

Question

Попытка смоделировать программную систему "производственный завод"...

В основе всей системы лежит "рабочий порядок" - почти каждый объект (многие из которых не показаны здесь или часть рассматриваемого AR) так или иначе связан с ним. Однако в первую очередь это выглядит так:

 + WorkOrder_Root
   + TrackingID: Property (UID)
   + DateReceived: Property
   + DateApproved: Property
   + PartName: Property
   + PartNumber: Property

   + Rework: Collection (1:m)

   + SerialLog: Collection (1:m)
   + CeriLog: Collection (1:m)

   + Sequences: Collection (1:m)
   + Dimensions: Collection (1:m)
   + Consumables: Collection (1:m)

   + Quoting: Single 
   + Invoice: Single 
   + Warranty: Single 
   + Certification: Single 

Это массивный AR (неполный - есть больше свойств / коллекций. Прочитав еще несколько статей и мини-книг за последние несколько дней, я серьезно задаюсь вопросом, должен ли я попытаться разложить на большее количество AR.

http://www.sapiensworks.com/blog/post/2013/05/13/7-Biggest-Pitfalls-When-Doing-Domain-Driven-Design.aspx

http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx

Все вышеперечисленные коллекции являются коллекцией сущностей, но ни одна из них не имеет смысла вне контекста рабочего задания.

Вы не можете выставлять счета без заказа на работу, вы не можете выставлять цены без заказа на работу, все зависит от заказа на работу.

Моей главной заботой является то, что я понимаю как потенциальные проблемы параллелизма. Например, если кто-то работает над W/O: 66354, изменяя цитату, а кто-то еще добавляет переработку, существует что-то вроде состояния гонки.

Изменения могут изменить цену, поэтому цитирование до завершения переделки заставляет меня задуматься, возможно, переделка должна быть ее собственным AR - но все переделки принадлежат рабочему заказу, вы не можете создать переделку без предварительного открытия / загрузки WorkOrder.

Все остальные мои AR в модели относительно простые, максимум 3 дочерних объекта и несколько свойств, но порядок работы - чудовище, и мне интересно, какого рода проблем я мог бы ожидать, имея этот объект "Бога"???

РЕДАКТИРОВАТЬ: я только что прочитал следующее ( http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html) Инварианты заставили меня подумать дважды. Если последовательность может быть обновлена ​​или изменена без необходимости информировать рабочий порядок, в котором она связана, то последовательности являются кандидатом в AR??? Последовательности могут быть плохим примером, так как изменения в последовательностях должны отражаться в WorkOrder_Root... но все же... я нахожусь здесь на правильном пути? Позволяя бизнес-правилам (а не логической или ориентированной на данные организации направлять путь?)...

С уважением, Алекс

Answer 1

Агрегаты не должны быть такими большими, как вы указали. Объекты, содержащиеся в агрегате, должны иметь высокую степень связи и иметь некоторые инварианты, которые должны выполняться постоянно. Инварианты между агрегатами только в конечном итоге согласованы. Вы не можете полагаться на них как действительные все время. Я мог бы представить, что вы можете безопасно защититься от таких несоответствий, которые вы описали с помощью двухэтапного процесса. Сначала проверьте предварительные условия. Сделай изменения. Проверьте еще раз, все ли в порядке. Если нет, отмените изменения и начните все сначала. Если у вас есть изменения, которые должны вызвать что-то еще, используйте доменные события. С ними вы можете свободно связать некоторые процессы.