Доменных службы управления детализацией

Question

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

DDD книги Эрика Эванса, стр. 108:

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

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

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

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

c) Книга DDD Эрика Эвана, стр. 108:

Coding конвенция может дать понять, что эти объекты являются только механизмами доставки для сервисных интерфейсов и не имеет смысл домен объектов.

Какие условные обозначения кодировки он имеет в виду?

UPDATE:

Я думаю, что вы говорите, что цитата описывает Services Application и неуслуги Доменные?

Я знаю служб приложений и их цели, но я думаю, что автор описывает Domain Services, так как он предупреждает, что знания утечки в Прикладной уровень может произойти из-за мелкозернистый доменных объектов:

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

И если мы хотим, чтобы предотвратить утечку знания из домена слоя в прикладном уровне, то не должен (по моей логике по крайней мере) «барьер» (то есть. среда -подготовленный сервис) будет построен в пределах доменного уровня?

ВТОРАЯ UPDATE:

)

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

Что это за сервис доменного имени Вы говорите? Один создан только с целью контроля гранулярности или ...?

б)

ИМО, это вопрос предпочтений, существует ли услуга приложения в отдельном проекте прикладного уровня или совместно с другими объектами домена.

Вы звоните услугу (цель которой является только управлять детализацией) службу Application даже если он существует в слое в домена?

с)

служба приложений делает прекрасную работу по предотвращению утечки знаний и в каком-то смысле, что его центральная работа.

Но так как «барьер» (то есть. среднезернистая сервис) существует в слое Application, разве это не означает, что домен знания делает утечку в слой Application (но не более того, благодаря Услуги по применению)?

d) Мы могли бы сказать, что Прикладного является клиентом из домена слой и автор не предупредят по всей книге, что нет домена знания MUST течи в клиента. Почему Application layer (т. Е. Службы приложений) исключение из этого правила?

Благодаря

Answer 1

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

Хотя сервисы не вносят никакого нового поведения в домен, они также не вводят понятия, отличные от домена. Я рассматриваю эти службы, application services, в частности, как обеспечивающий инкапсуляцию роли для домена - facade. Каждый метод службы представляет собой случай использования домена, и он делегирует непосредственно объектам домена. Это значительно облегчает клиентам доменного уровня, поскольку им не нужно беспокоиться о координации репозиториев и вызывать подходящие поведенческие методы для агрегатов. Вместо этого они вызывают метод в службе приложения.

b) Должна ли большая часть связи с верхними слоями проходить через объекты среднего размера? Таким образом, для каждого случая использования, когда связь осуществляется через мелкозернистые объекты домена, мы должны внедрить услуги (-ы) среднего уровня домена?

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

Какие условные обозначения кодировки он имеет в виду?

одной конвенции может быть наличие в заявке имя службы, такие как CargoApplicationService. Другое соглашение заключается в размещении приложений, которые BTW также могут быть реализованы как обработчики команд, в модуль Приложение в рамках проекта.

EDIT

Посмотрите this project on GitHub который реализует область, описанную в книге в современном C# стиле.

UPDATE

Что касается зернистости, служба домена выполняет ту же роль службы приложения. ИМО, вопрос о том, существует ли служба приложений в отдельном проекте уровня приложения или вместе с другими объектами домена, является предпочтительным. Создание дополнительного барьера между службой приложений и объектами домена может стать ненужной абстракцией. Служба приложений прекрасно справляется с предотвращением утечек знаний и, в некотором смысле, является его центральной работой.

UPDATE 2

а) Я говорил о доменных услугах в целом, поскольку все они имеют тенденцию к увеличению детализации за пределами субъектов и ВО.

b) Да, поскольку он по-прежнему захватывает понятия домена, а именно, использует случаи, которые менее гранулированы, чем объекты домена, используемые для их реализации. Уверен, что служба приложений имеет проблемы, которые в основном ортогональны домену, но не всегда есть причина поместить их в разные уровни.

c) Да, но вы не можете обойти все знания домена. Если у вас есть таблица базы данных с именем «Клиенты», которое соответствует объекту «Клиент», у вас есть данные о доменах, просочившиеся в базу данных. Дело не в том, чтобы предотвратить все утечки, а вместо этого создавать границы вокруг областей сплочения, так что при внесении изменений они могут быть выделены на определенный уровень.

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