Где создавать объекты значений в CQRS и потоке DDD - PullRequest
1 голос
/ 10 января 2020

Я борюсь со строительством ValueObjects в течение жизненного цикла команды.

Вот моя ситуация:

  1. Командный запрос приходит к действию контроллера.
  2. Создание объекта команды с параметрами запроса.
  3. Передача объекта команды в служба приложений
  4. Обработчик команд сначала проверяет атрибуты команды
  5. , затем создает агрегат и передает атрибуты команды в агрегатную функцию.
  6. и агрегатные функции передают атрибуты в событие домена.

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

Ответы [ 2 ]

1 голос
/ 10 января 2020

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

Обычный ответ - создание объекта домена происходит через «фабрики» (см. Эванс, глава 6), которые обычно экспортируются из модели предметной области и вызываются кодом приложения, которому они нужны.

Фабрика может быть самостоятельным объектом или просто быть функцией или даже конструктором.

Обзор DDDSample Citerus может помочь проиллюстрировать:

https://github.com/citerus/dddsample-core/blob/master/src/main/java/se/citerus/dddsample/interfaces/booking/web/CargoAdminController.java#L133

Здесь, контроллер извлекает необходимые данные (как примитивы) и передает эту информацию в changeDestination logi c.

https://github.com/citerus/dddsample-core/blob/master/src/main/java/se/citerus/dddsample/interfaces/booking/facade/internal/BookingServiceFacadeImpl.java#L74

В следующем классе в , строки заменены на Value Objects; в этом случае конструктор TrackingId и конструктор UnLocode реализуют роль фабрики. Затем объекты-значения передаются в changeDestination logi c.

1 голос
/ 10 января 2020

Вы можете делегировать создание доменных моделей в другие сервисы, собственно, они являются частью доменных сервисов. вы можете передать им некоторые примитивные данные или DTO и, наконец, вы можете ожидать от них действительную модель домена. Общие шаблоны, которые я могу упомянуть, это Factory Pattern или Builder Pattern, обычно они используют защищенный конструктор модели домена для создания новой модели домена. Обратите внимание, что конструктор вашей доменной модели должен быть защищен пакетами, и только ваши доменные службы могут создавать ваши доменные модели. это означает, что конструктор модели вашего домена не должен быть доступен из вашего основного домена, и для создания моделей домена вы можете внедрить доменные службы (фабрики, сборщики) в сценарии использования или службы приложений.

...