DDD когда выделять побочные эффекты в доменные сервисы

Question

Скажем, у меня есть сущность ShippingOrder, которая состоит, среди прочего, из объекта значения RouteSpecification.

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

Должен ли я строить RouteSpecification внутри RouteSpecificationDomainService или это просто использоваться для проверки перед построением модели?

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

Если это последняя, ​​то мне просто нужно верить, что она используется потребителями должным образом или есть дополнительная абстракция для защиты от злоупотреблений?

Answer 1

Идомати c DDD здесь будет использоваться Factory.

Фабрика в DDD отвечает за создание действительного Агрегата (со всеми инициализированными объектами и объектами-значениями). Factory - это компонент, который может использовать любые зависимости (даже те, что связаны с внешними системами), необходимые для обеспечения такого поведения.

Поскольку заказ на доставку является вашим агрегатом, ShippingOrderFactory должны быть предоставлены все аргументы и зависимости для построения объект , даже если они не используются в конечном объекте

Answer 2

Если RouteSpecification является объектом значения, то нет, он не должен иметь свою собственную службу домена. Только агрегаты root.

Однако ShippingOrderService может иметь метод GenerateRoute, который принимает origin и destination и возвращает действительный маршрут.

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