Что такое доменная служба?
В тактическом моделировании не все модели являются вещами. Некоторые модели моделируют некоторые поведенческие операции в предметной области. Мы называем такие модели доменными службами. Когда некоторые важные операции предметной области не могут быть помещены в сущности, объекты-значения или агрегаты, они, по сути, являются поведением, а не вещами. Если мы не будем искать какие-то объекты для инкапсуляции поведения этой предметной области, это перерастет в прежний процедурный стиль программирования. Мы хотим унифицировать взаимодействие с объектами модели в предметной области. На этом этапе службы предметной области используют детализированные объекты предметной области, такие как сущности или объекты-значения, для взаимодействия, описания знаний предметной области в пределах службы, а также для получения результатов и их возврата.
Типы параметров и возвращаемых данных доменных служб должны быть объектами домена.
Три особенности:
- Это операция, связанная с предметной областью, такая как выполнение важного процесса бизнес-операции, но она не подходит для объектов Entity и Value.
- Операции не имеют состояния.
- Преобразование выполняется над объектом домена или выполняется вычисление с несколькими объектами домена в качестве входных данных, в результате чего получается объект значения.
Суммировать: Когда важный процесс или операция преобразования в домене не является естественной обязанностью сущностей и объектов-значений, операция должна быть добавлена в модель как отдельный интерфейс и объявлена как сервис домена. Используйте язык схемы при определении интерфейсов и убедитесь, что имена операций являются терминами на унифицирующем языке бизнеса. В дополнение к этому доменная служба должна быть без сохранения состояния.
Нам нужно понять степень.Если все знания предметной области инкапсулированы в сущности, модель будет перегружена из-за чрезмерного поведения.В случае перегрузки поведение многих сущностей неохотно и неестественно. Если мы инкапсулируем поведение в доменную службу, модель будет анемичной из-за отсутствия поведения, и мы вернемся к традиционному режиму разработки.
Различия между различными услугами
В традиционной разработке у нас уже есть понятие Service, и когда мы вводим доменные сервисы, мы можем начать путаться. В дизайне, ориентированном на домен, мы в основном делим службы на три категории: одна — служба приложений, другая — служба домена, а третья — базовая служба. Как отличить эти три услуги? Мое простое понимание состоит в том, чтобы различать клиентов, обслуживаемых самой службой. Служба приложений предоставляет услуги, ориентированные на пользователя, и то, что она выполняет, является полным требованием пользователя. Службы предметной области предоставляют службы, ориентированные на прикладной уровень, и их цель — инкапсулировать знания предметной области для использования на прикладном уровне. Базовый сервис предоставляет услуги для прикладного уровня и доменного уровня, а также предоставляет общие функции, которые могут использоваться всеми уровнями в проекте.
Давайте рассмотрим пример банковского перевода, чтобы проиллюстрировать, что обрабатывают различные службы.
- Служба приложения: получает входные данные, отправляет сообщение на уровень домена, прослушивает сообщение подтверждения, решает использовать базовую службу для отправки электронной почты.
- Служба домена: координируйте взаимодействие между моделью учетной записи и моделью главной книги и выполняйте соответствующее поведение домена.
- Базовая служба: отправляйте почту в соответствии с указаниями службы приложений.
детализация
Прикладной уровень отвечает за координацию поведения объектов домена для удовлетворения потребностей определенного домена. Но если объекты предметной области представляют собой детализированные объекты, такие как сущности и объекты-значения, прикладной уровень должен понимать, как эти детализированные объекты взаимодействуют, чтобы соответствовать требованиям предметной области. В это время знания в предметной области просачиваются на прикладной уровень. Мы должны попытаться избежать утечки знаний о предметной области на прикладной уровень. В настоящее время служба предметной области является хорошим способом справиться с этим.Посредством инкапсуляции мелких объектов предметной области в службы предметной области знания предметной области ограничиваются службами предметной области, и формируются объекты предметной области общего назначения. Поэтому, когда прикладной уровень вызывает службы предметной области общего назначения, ему не нужно заботиться о сложных взаимодействиях объектов.
процесс преобразования
Давайте возьмем функцию, которая должна подсчитывать ежедневную книгу в системе магазина, и поместим эту функцию в службу статистики книги. Мы передаем сущность и дату магазина, используем библиотеку ресурсов репозитория (такую же, как DAO) в методе для получения модели домена, а затем используем взаимодействие между моделями домена для завершения учета реестра и, наконец, инкапсулируем его в модель бухгалтерской книги и вернуть ее.
public class LedgerAccountor {
public LedgerSumary ledgerSumary(Shop aShop, Date date){
int totalIncome = 0;
int totalExpense = 0;
List<ShopTrade> trades = ShopTradeRepository.getShopTrades(ashop,date);
for(ShopTrade trade : trades){
totalIncome += trade.getIncome();
totalExpense += trade.getExpense();
}
return new LedgerSumary(totalIncome, totalExpense);
}
}