Идея DDD заключается в том, что модель предметной области содержит ваши данные и большую часть бизнес-логики. Службы обычно имеют дело с постоянством этих структур.
Тогда есть все те промежуточные случаи, когда бизнес-процесс состоит из нескольких шагов, которые неизменно изменяют / модифицируют доменные объекты. Обычно вы используете сервисы для реализации какого-либо процесса. Поэтому, как правило, вы обновляете доменные объекты с помощью результатов сервисов. Вы никогда не позволяете реализациям доменного объекта сами вызывать службы!
Так что довольно часто можно увидеть код, подобный этому:
if (order.isValidForPurchase() && orderValidatorService.isValidOrder( order))
orderService.order( order)
Просто потому, что части правды известны объекту порядка, а некоторые требуют внешних данных, известных orderValidatorService. Возможно, эти две строки кода также могут быть внутри метода orderService.order.
Я думаю, что всегда стоит исследовать, КАК много доменных объектов существует в этих процессах, иногда многое можно получить, создав больше концепций, чем вы думаете. Это действительно пересечение состояний бизнес-процессов и объектных моделей. Зачастую модели DDD стремятся захватить домен с чрезмерно структурной точки зрения, IMO игнорирует основные процессы слишком сильно. Поэтому, если вы чрезмерно структурны, я думаю, вы создаете объект Order. Если вы добавите процесс, возможно, вы сделаете ShoppingCartOrder, UnshippedOrder, ShippedOrder, BilledOrder и HistoricalOrder. Это также иногда упрощает интеграцию вашего сервиса.