DDD: ссылка на не-корни. Альтернатива?

В настоящее время я работаю над приложением, Facilitiesс которым управляются Facility Itemsи Assessmentsс которым Findingsуправляют (это мобильное приложение с приложением для управления Windows, и я описываю его лишь небольшую часть).

В настоящее время он реализован очень CRUD с анемичной моделью, и я хотел бы применить некоторые идеи от DDD, чтобы сделать мою модель более богатой / надежной и обеспечить соблюдение некоторых инвариантов.

Новое требование, которое я хотел бы реализовать, - получить информацию об объектах / результатах объекта, сканируя Tagприкрепленное к ним.

Упрощенная модель

У Teamвладельца есть предопределенный набор тегов. В настоящее время это некоторые коды qr, напечатанные на магнитных ярлыках, но, конечно, теги nfc также могут использоваться. В то время как член команды выполняет оценку, всякий раз, когда он идентифицирует обнаружение, он помещает тег в «цель» и просматривает его. Позже другие члены команды могут сканировать существующий тег и получать информацию об обнаружении. Если обнаружение больше не актуально, тег может быть повторно использован для других результатов.

Это мои (простые) требования:

  • Тег может быть назначен либо объекту, либо найденному.
  • Если тег переназначен, старое назначение перестает быть активным.
  • Можно запросить объект / поиск объекта с помощью тега.

Простым / очевидным решением является ссылка на тег непосредственно из объекта find / facility. Но я думаю, что у этого есть некоторые недостатки:

  1. Возможно, потребуется изменить два AR в одной транзакции, например, если тег был ранее использован для поиска и теперь используется для объекта объекта
  2. Я думаю, объект объекта не должен знать ничего о теге. На самом деле это не свойство, не так ли?
  3. Я использую Оптимистическую блокировку, а изменение «назначения» также изменит элемент поиска / объекта и владельца AR. Думаю, это может привести к проблемам параллелизма.

Я думал, что я мог бы использовать какое-то свойство «Назначение тегов» со ссылками на тег и на объект / поиск объекта. С помощью этого решения я мог бы легко изменить назначение. Имеет ли это смысл? Но по крайней мере одна проблема с этим решением: Ссылка на объект объекта / обнаружение из тега «не разрешена» в DDD (потому что нужно ссылаться только на AR).

Интересно, как кто-то будет моделировать это с помощью DDD? Есть предположения? Спасибо!

c#,oop,design,domain-driven-design,

1

Ответов: 1


0

Я думал, что я мог бы использовать какое-то свойство «Назначение тегов» со ссылками на тег и на объект / поиск объекта. С помощью этого решения я мог бы легко изменить назначение. Имеет ли это смысл? Но по крайней мере одна проблема с этим решением: Ссылка на объект объекта / обнаружение из тега «не разрешена» в DDD (потому что нужно ссылаться только на AR).

Интересно, как кто-то будет моделировать это с помощью DDD? Есть предположения?

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

В настоящее время это некоторые коды qr, напечатанные на магнитных ярлыках, но, конечно, теги nfc также могут использоваться. Хотя член команды выполняет оценку, всякий раз, когда он идентифицирует обнаружение, он прикрепляет тег к «цели» и просматривает его

Обратите внимание, что эти действия происходят в реальном мире; ваша модель домена не получает право вето.

Второе, что нужно заметить, это то, что, хотя Tagможет быть сущностью в реальном мире, вам на самом деле не все равно. Ваш сканер отскакивает от ярлыка, анализирует отражение, передает QR-код и отправляет представление этого QR-кода. (Картина вашей модели уже предполагает, что вы это понимаете).

Если обнаружение больше не актуально, тег может быть повторно использован для других результатов.

Это звучит так, как ваша модель должна понимать время . Люди в реальном мире хотят, чтобы вы могли рассказать свою модель «На момент {date: ...}, тег {qrcode: ...} был назначен Finding {id: ...}"

Команде принадлежит предопределенный набор тегов.

Вам нужно много думать о том, что на самом деле означает ваша собственность. В описании проблемы нет ничего, что говорит о том, что команда AR отвечает за поддержание бизнес-инварианта относительно состояния тега. Если бы команда была реорганизована из своего существования, все ее теги «ушли»? Возможно нет.

Я предполагаю, что собственность больше похожа на назначение «С точки зрения {date: ...}, Team {id: ...} отвечает за Tag {qrcode: ...}"; и снова - вам нужно обратить пристальное внимание на «кто решит?» Модель? или реальный мир?

C #, ООП, дизайн, домен привод-дизайн,
Похожие вопросы