DDD Пользовательские свойства по динамической композиции документа/объекта

Мы реорганизуем наше решение в структуру проектирования, управляемого предметной областью. Наши консультанты, занимающиеся внедрением программного обеспечения, должны иметь возможность настроить некоторое поведение приложения (под конкретные нужды заказчика). Например, они хотят добавить в презентацию настраиваемые свойства (формы ввода пользователя) и сохранить пользовательские данные вместе с объектами, определенными в наших проектах DDD.

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

Как сделать этот сценарий возможным? Одним из возможных решений может быть:

  • Запросите объект, используя его репозиторий
  • И запросите отдельно CustomPropertiesRepository по идентификатору объекта.
  • Объедините два объекта запросов.
  • При сохранении форм. Он будет снова разделен с использованием двух репозиториев.

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

Любые советы по этой проблеме?


domain-driven-design ddd-repositories
person Kees Schouten    schedule 29.03.2017    source источник
comment
Однако я не хочу, чтобы объекты предметной области знали о наличии настраиваемых свойств. Что вы имеете в виду?   -  person Constantin Galbenu    schedule 29.03.2017
comment
Изменено описание, чтобы было понятнее.   -  person Kees Schouten    schedule 29.03.2017
comment
Может быть, мне следует использовать какую-то форму проекций, чтобы объединить эти 2 (домен и пользовательские данные) в единое целое...   -  person Kees Schouten    schedule 29.03.2017
comment
Недостатком этого является то, что мне нужно дважды запрашивать, хотя это должен быть один документ. не вижу в этом проблемы   -  person Constantin Galbenu    schedule 29.03.2017
comment
какая-то форма прогнозов. Используете ли вы CQRS?   -  person Constantin Galbenu    schedule 29.03.2017
comment
Нет, я просто использую DDD   -  person Kees Schouten    schedule 29.03.2017
comment
Однако желательно, чтобы объекты предметной области не содержали свойства customData. Но почему?   -  person Constantin Galbenu    schedule 29.03.2017
comment
@KeesSchouten Ваша проблема слишком абстрактна. Это вообще не говорит о бизнесе. Какую бизнес-задачу решает эта часть программы? Как вы думаете, почему эти настраиваемые поля данных не следует моделировать в предметной области? Существуют ли инварианты для применения в отношении этих настраиваемых полей данных?   -  person plalx    schedule 30.03.2017
comment
ммм кажется, что эти пользовательские свойства являются частью вашего домена. Почему вам не нравится иметь объект-значение CustomProperties, обертывающий карту в вашей сущности?   -  person rascio    schedule 30.03.2017
comment
Кто является пользователем вашего программного обеспечения? Вы явно используете термин «настраиваемое свойство» при обсуждении с ними проблемы? Если да, то настраиваемое свойство, вероятно, является концепцией вашей предметной области и поэтому должно быть включено в вашу модель. В противном случае кажется, что этот дизайн вонючий, и его следует избегать. Пожалуйста, попробуйте добавить несколько примеров.   -  person Mike Wojtyna    schedule 30.03.2017

Ответы (1)


arrow_upward
0
arrow_downward

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

в DDD код должен отражать знание предметной области, он должен быть простым и явным.

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

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

person Nabil Sedoud    schedule 03.12.2018