Разработка домена: доменная служба, служба приложений

Может кто-нибудь объяснить разницу между доменами и приложениями, предоставив несколько примеров? И если служба - это служба домена, я бы поставил фактическую реализацию этой службы в сборку домена, и если да, я бы также добавил репозитории в эту службу домена? Некоторая информация была бы действительно полезной.

ОТВЕТЫ

Ответ 1

Сервисы бывают трех видов: доменные, прикладные и инфраструктурные.

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

Держать доменные службы вместе с вашими доменными объектами разумно - все они сосредоточены на доменной логике. И да, вы можете внедрить репозитории в свои сервисы.

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

Надеюсь, это поможет!

Ответ 2

(Если вам не нравится читать, в нижней части есть сводка: -)

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

Другие ресурсы

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

Статья в MSDN Magazine Введение в управляемый доменом дизайн описывает приложения-службы как способ преобразования и/или предоставления вашей модели домена внешним клиентов, например как служба WCF. Вот как Vijay также описывает приложения. С этой точки зрения службы приложений являются интерфейсом к вашему домену.

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

Мои мысли

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

Домен

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

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository

В основной сборке реализованы классы Product и ProductFactory. IProductRepository - это то, что, вероятно, поддерживается базой данных. Реализация этого не относится к области и поэтому определяется интерфейсом.

В настоящее время мы сосредоточимся на IExchangeRateService. Бизнес-логика для этой услуги реализуется внешним веб-сервисом. Однако его концепция по-прежнему является частью домена и представлена ​​этим интерфейсом.

Инфраструктура

Реализация внешних зависимостей является частью инфраструктуры приложения:

My Solution
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - DomainServices
      XEExchangeRateService
    SqlServerProductRepository

XEExchangeRateService реализует службу домена IExchangeRateService, обмениваясь с xe.com. Эта реализация может использоваться вашими приложениями, использующими вашу модель домена, путем включения сборки инфраструктуры.

Применение

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

public class CachingExchangeRateService : IExchangeRateService
{
    private IExchangeRateService service;
    private ICache cache;

    public CachingExchangeRateService(IExchangeRateService service, ICache cache)
    {
        this.service = service;
        this.cache = cache;
    }

    // Implementation that utilizes the provided service and cache.
}

Обратите внимание на параметр ICache? Эта концепция не является частью нашего домена, поэтому это не служба домена. Это служба приложений. Это зависимость нашей инфраструктуры, которая может быть предоставлена ​​приложением. Введем приложение, которое демонстрирует это:

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - ApplicationServices
      ICache
  - DomainServices
      CachingExchangeRateService
      XEExchangeRateService
    SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
  - ApplicationServices
      MemcachedCache
    IMyWcfService.cs
  + MyWcfService.svc
  + Web.config

Все это входит в приложение следующим образом:

// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);

ServiceLocator.For<IExchangeRateService>().Use(cachingService);

Резюме

Полное приложение состоит из трех основных слоев:

  • домен
  • Инфраструктура
  • Приложение

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

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

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

Хотя эта перспектива может не совпадать с общим определением служб DDD, она отделяет домен от приложения и позволяет вам совместно использовать сборку домена (и инфраструктуры) между несколькими приложениями.

Ответ 3

Лучший ресурс, который помог мне понять разницу между Службой приложений и доменной службой, - это java-реализация примера груза Eric Evans, найденного здесь. Если вы его загрузите, вы можете проверить внутренние службы RoutingService (доменная служба) и BookingService, CargoInspectionService (которые являются приложениями).

Мое "ага" было вызвано двумя вещами:

  • Считывание описания Сервисов по ссылке выше, точнее это предложение:

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

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

Ответ 4

Из Красной книги (Внедрение доменного дизайна, Вон Вернон), вот как я понимаю концепции:

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

Доменные службы инкапсулируют такое поведение, которое не вписывается в один объект домена. Например, библиотека книг, предоставляющая Book Client (с соответствующими изменениями Inventory), может делать это из службы домена.

Службы приложений обрабатывают поток сценариев использования, включая любые дополнительные проблемы, необходимые в дополнение к домену. Он часто предоставляет такие методы через свой API для использования внешними клиентами. Чтобы построить наш предыдущий пример, наш сервис приложений может предоставить метод LendBookToClient(Guid bookGuid, Guid clientGuid) который:

  • Получает Client.
  • Подтверждает свои разрешения. (Обратите внимание, как мы избавили нашу модель предметной области от проблем безопасности/управления пользователями. Такое загрязнение может привести ко многим проблемам. Вместо этого мы выполняем это техническое требование здесь, в нашей службе приложений.)
  • Получает Book.
  • Вызывает службу домена (передавая Client и Book) для обработки фактической доменной логики предоставления книги клиенту. Например, я предполагаю, что подтверждение доступности книги определенно является частью логики предметной области.

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

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

Ответ 5

Служба домена - это расширение домена. Это видно только в контексте домена. Это не какое-то действие пользователя, например, закрытие учетной записи или что-то еще. Служба домена подходит там, где нет состояния. В противном случае это будет объект домена. Служба домена делает что-то, что имеет смысл только при выполнении с другими сотрудниками (объектами домена или другими службами). И смысл в том, что это ответственность другого уровня.

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

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

Ответ 6

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

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

Millett, C (2010). Профессиональные шаблоны проектирования ASP.NET. Wiley Publishing. 92.

Ответ 7

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

  • У вас есть 2 агрегата:

    • Product, который содержит имя и цену.
    • Purchase, который содержит дату покупки, список продуктов, заказанных с указанием количества и цены продукта на тот момент, и способ оплаты.

  • Checkout не входит ни в одну из этих двух моделей и является концепцией вашего бизнеса.

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

Службы приложений. Служба, которая "координирует" или использует методы домена. Это может быть так просто, как просто ваш контроллер.

Это место, где вы обычно делаете:

public String createProduct(...some attributes) {
  if (productRepo.getByName(name) != null) {
    throw new Exception();
  }

  productId = productRepository.nextIdentity();

  product = new Product(productId, ...some attributes);

  productRepository.save(product);

  return productId.value();
  // or Product itself
  // or just void if you dont care about result
}

public void renameProduct(productId, newName) {
  product = productRepo.getById(productId);

  product.rename(newName);

  productRepo.save(product);
}

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

Вот полный пример проекта DDD: https://github.com/VaughnVernon/IDDD_Samples

Вы можете найти множество примеров службы приложений и пару доменных служб

Ответ 8

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

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

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

Для упрощения мы рассмотрим только 2 доменных объекта: Door и Lamp, каждое из которых имеет 2 состояния, соответственно open/closed и on/off, и специальные методы для управлять изменениями состояния на них.

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

Мы можем назвать нашу службу домена как DomoticDomainService и реализовать 2 метода: OpenTheDoorAndTurnOnTheLight и CloseTheDoorAndTurnOffTheLight, эти 2 метода соответственно изменяют состояние обоих объекты Door и Lamp - open/on и closed/off.

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

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