Ассоциация между агрегатами, как выбрать между хранением ссылки на объект или только на его идентичность - PullRequest
Новая
       81

Ассоциация между агрегатами, как выбрать между хранением ссылки на объект или только на его идентичность

0 голосов
/ 12 декабря 2018

Например, предоставление исполнения с несколькими исполнителями ...

Первый вариант: 

Performance (1) ---> (*) Performer

Второй вариант: 

Performance
+PerformerIds[]

1-й вариант Плюсы:

  • Упрощенный доступ для целей запроса (допустим, я не хочу использовать CQRS)
  • Когда мы смотрим на модель предметной области, кажется, что легче понять связь между производительностью и исполнителем* более заметна

1-й вариант Минусы:

  • Объект Performance тяжелее загружать (возможно, это можно исправить с помощью отложенной загрузки)
  • Больше сцепления

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

Iвроде как первый вариант, потому что объект Performance никогда не будет использовать объект Performer.Это отношение больше похоже на отношение данных / модель запроса.Но это также делает диаграмму модели предметной области менее понятной, на мой взгляд, поэтому я не уверен, стоит ли мне использовать какое-либо решение.

Может ли моя проблема заключаться в том, что я пытаюсь использовать тот же класс?диаграммы для экспертов в области и для разработчиков?и / или моделирование для запроса, а не для обновления?

1 Ответ

0 голосов
/ 17 декабря 2018

как выбрать между хранением ссылки на объект или только на его идентичность

Хранение ссылки на идентичность связанных агрегатных корней (AR) делает их границы явными.

Конечно, каждый AR по-прежнему содержит ссылки на все свои сущности, но в вашей доменной модели становится очень явным, ссылаетесь ли вы на совокупные корни или сущности.

  • Если у вас есть ссылки на связанные Агрегированные Корни (AR), очень легко пересечь границы между ними.
  • Может быть очень легко изменить несколько агрегатов одновременно, особенно если вы используете ORM или внедрили Unit of Work.Таким образом, ваши совокупные корни больше не являются границами транзакции.
  • Если вы держите только идентификаторы для связанных Агрегированных Корней (AR), для доступа к связанному AR вы должны сначала загрузить его из репозитория.Это компромисс.Это становится очень явным, когда вы пересекаете границу одного агрегата и запрашиваете другой.

Что мне не нравится в этом, так это то, что когда вы смотрите на диаграмму классов, все, что вы видитеэто отдельные агрегаты, которые не имеют никакой связи между ними, и которые не выглядят очень полезными для демонстрации связанных понятий домена.

Ваша модель домена является "моделью", и вам решатьпринимать решения по проектированию.

Если все ваши совокупные корни малы, и вы используете ORM, который делает много волшебства бесплатно (ПРИМЕЧАНИЕ: всегда есть цена), и значение просмотра ссылок на классдиаграмма больше значения видимости границ, затем попробуйте сохранить ссылку на связанные AR, даже если ваш код на самом деле не нуждается в этом.

А затем оцените вашу модель с течением времени.

...