Попытка смоделировать систему программного обеспечения «производства завода» ...DDD Совокупный корень дизайн
В основе всей системы является «WorkOrder» - почти каждый объект (многие из тех, которые здесь не показаны или часть рассматриваемого 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/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
всех вышеперечисленных коллекций коллекции сущностей, но ни один из которых имеет смысла вне контекста ш орков.
Вы не можете выставлять счет без заказа на работу, вы не можете указывать без заказа на работу, все зависит от заказа на работу.
Моя основная проблема заключается в том, что я понимаю, что это потенциальные проблемы параллелизма. Например, если кто-то работает над W/O: 66354, изменяя цитату, а кто-то еще добавляет переработку, есть что-то вроде состояния гонки.
Reworks может изменить цену, поэтому цитирование перед завершением доработки, заставляет меня думать, возможно, переделка должна быть его собственным AR - но все переустройства принадлежат к рабочему заказу, вы не можете построить переделку без первого открытия/загрузки WorkOrder.
Все мои другие AR в модели относительно просты не более 3 дочерних объектов и несколько свойств, но рабочий заказ - это зверь, и мне интересно, какие типы проблем я могу ожидать, имея этот объект «Бог»? ??
EDIT: Я только что прочитал следующее (http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html) Инварианты заставил меня думать дважды. Если последовательность может быть обновлена или изменен без необходимости указания порядка работы, в котором он связан , то последовательности являются кандидатом для AR ??? Последовательности могут быть плохим примером, поскольку изменения в последовательности необходимо отразить в WorkOrder_Root ... но все же ... я на правильном пути здесь? Позволить бизнес-правил (а не логической или данных, ориентированных на организацию направлять путь?) ...
С уважением, Alex
Только что нашел эту статью: http: // lostechies.com/jimmybogard/2010/02/24/укрепление-your-domain-aggregate-construction/ ut вне проверки являются инвариантами сущности. Инварианты суть суть того, что означает, что сущность является сущностью. Мы можем спросить наших клиентов, может ли Человек быть Лицом (в нашей системе) без BirthDate? В этом случае почти все объекты (гарантия, сертификация, счет-фактура, цитата и т. Д.) Не являются инвариантами и заслуживают собственного AR? Рабочий заказ может существовать без цитаты (он неполный, но это происходит). –
Чтобы добавить к примечанию выше, рабочий заказ не может быть выставлен счет без цитаты - так как это будет выглядеть как AR? Вы не можете создать цитату без рабочего порядка - теперь моя голова крутится в кругах :) –
Наконец ... если Quoting не является дочерним объектом WorkOrder - как мы гарантируем, что с ним связан правильный рабочий порядок? Это делается при проверке метода сохранения котировок ??? –