В DDD доменная служба по сути является просто шаблоном фасада и / или посредника?

В домене, управляемом дизайном, уровень домена может иметь несколько (традиционных) сервисов. Например, для пользовательского домена мы можем иметь:

UserFactory, который строит объекты User различными способами.
UserRepository, который отвечает за взаимодействие со службами постоянства на уровне инфраструктуры

Является ли UserService на уровне домена просто посредником и / или фасадом для этих двух служб и уровня инфраструктуры, или это еще не все?

object-oriented object-oriented-design domain-driven-design

— e_i_pi
источник

Смотрите также Услуги в DDD и Услуги в DDD

— Эрик Эйдт

Я много читал посты об уровне Городинского, хотя никогда не видел эту вторую ссылку. Отличное чтение, определенно затрагивает некоторые важные моменты!

— e_i_pi

Ответы:

Domain services лучше всего описать, чем они не являются:

они не являются EntitiesниAggregate roots
они не Value objects
нести знания предметной области, которые естественно не соответствуют только одному Entity или одному Value object

Пример a Domain service: a Saga/Process manager: он координирует длительный процесс, включающий несколько Aggregate rootsвозможных из разных Bounded contexts.

При этом, что такое Domain serviceи как это реализовано - две ортогональные вещи.

Является ли UserService на уровне домена просто посредником и / или фасадом для этих двух служб и уровня инфраструктуры, или это еще не все?

Некоторые доменные службы, такие как UserRepository(составленный из интерфейса, определенного в Domain layerи конкретной реализации в Infrastructure layer), могут быть реализованы с использованием Facadeшаблона проектирования. Других доменных служб нет.

Не существует жесткого правила о том, как их реализовать, кроме важного правила о том, что оно Domain layerне должно зависеть от других уровней (и SOLID ).

— Константин Гальбену
источник

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

— e_i_pi

Бизнес-правила @e_i_pi защищены только агрегатами и их вложенными объектами. Доменные службы не участвуют в этом.

— Константин Гальбену

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

— Константин Гальбену

@e_i_pi: Я думаю, у вас есть несколько заблуждений. Итак, весь Domain Layer - это программная модель вашего домена. Вы сказали - «Наряду с хранением объектов данных (агрегатов, сущностей и объектов значений)» - это не «объекты данных» в том смысле, что они просто содержат данные; они фактически реализуют правила домена, они определяют поведение. Теперь доменные службы , согласно книге DDD Э. Эванса , - это те аспекты домена, которые не вписываются в объект (объект или объект стоимости).

— Филипп Милованович

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

— Филипп Милованович

Я вижу услуги в DDD как результат инверсии зависимости .

Если бы вы использовали «простые» зависимости, тогда ваш код домена вызывал бы базу данных для сохранения или запроса сущности или фабрики, которая создает сущность, которая связана с базой данных или внешней службой или каким-либо другим кодом инфраструктуры.

Но это не то, каким должен быть код домена. Код домена не должен зависеть от кода инфраструктуры. Поскольку эта зависимость затрудняет тестирование и, возможно, повторное использование. Вот почему вы инвертируете эту зависимость. Вы делаете код инфраструктуры зависимым от кода домена. И для этого вам нужно ввести абстракцию. Абстракция, определяющая, какое поведение доменный код ожидает реализовать инфраструктурой.

А сервисы в DDD - это та абстракция. В большинстве случаев для кода домена эти сервисы должны быть простыми интерфейсами. И реализация должна быть в коде инфраструктуры, который зависит от этих интерфейсов.

— Euphoric
источник

Спасибо за ваш ответ, оба ответа вместе дали мне «ага!» момент. Думаю, без вашего ответа я бы не полностью понял концепцию, но предпочитаю ответ Константина в качестве индикатора для будущих читателей.

— e_i_pi