Цель услуг по внедрению CQRS Грега Янга

Question

Я решил познакомиться с конкретной реализацией CQRS на примере реализации Грега Янга

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

Клиент изменяет полученный DTO и создает команду, которая обрабатывается его обработчиком, который вызывает метод объекта домена.

Затем событие создается и сохраняется в хранилище событий и публикуется для синхронизации денормолизированной части.

Я не могу найти услугу в этой цепочке.

Мой коллега сказал мне, что, например, если мы не хотим хранить большие данные как часть домена, когда мы храним их в отчетах, но когда нам это нужно, в нашем домене мы публикуем событие, которое возвращает что-то из службы ,

Но я не могу четко представить себе картину.

Может кто-нибудь объяснить, что услуги должны делать здесь?

Answer 1

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

Answer 2

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

Однако в CQRS выобычно имеют службу команд и службу запросов , которые в контексте DDD представляют уровень службы приложений .Но, как я уже сказал, читая статью, я думаю, что его использование слова «сервис» предназначено для доменных сервисов.

Answer 3

Если у вас есть проблемы, такие как Set Consistency Validation. Например: Установить сообщение проверки в SO , вам может потребоваться служба, обеспечивающая отклонение входящих дублирующих команд со значением, которое должно сохраняться только один раз. В этом случае служба в основном выполняет вставку в таблицу Sql с ограничением первичного ключа. Это происходит только один раз, в противном случае выдается ошибка, и весь процесс завершается неудачно, а события не генерируются, а отчеты на стороне запроса отсутствуют. Просто дело.

Answer 4

Вы имеете в виду об обслуживании удаленного фасада (веб-службы), который будет вызывать прикладной уровень, потому что доменная служба - это другое.

Уровень удаленного фасада (веб-сервис), если вы разрабатываете n-уровневое приложение для предоставления сервисов приложений другим уровням, откроет ваш бизнес и команды, вызвав уровень приложения, уровень приложения, как упомянул Дэвид:

Для Read Part, на вашем прикладном уровне вам нужно спроектировать Query Service с такими методами, как FindOrders(x, y, z), GetMostOrderedItems(), ...

Для части Write вы можете спроектировать службу команд одним из следующих способов:

• Служба, которая принимает DTO и выполняет доменную логику на ее основе [Least CQRS]:

public void ActivateOrder(int orderID)
{
    var order = _orderRepository.FindOrder(orderID);
    order.Activate();
}

public void UpdateClientAddress(ClientAddressDTO address)
{
    var client = _clientRepository.FindClient(address.ClientID);
    client.Address = // .. map ClientAddressDTO to Address
}

• Служба, которая принимает DTO и преобразует их в Команду, выполняемую в доменной модели:

public void ActivateOrder(int orderID)
{
    var orderActivationCommand = new OrderActivationCommand(orderID);
    _commandExecuter.Execute(orderActivationCommand);
}

public void UpdateClientAddress(ClientAddressDTO address)
{
    var clientMovingCommand = new clientMovingCommand(address.ClientID, address.PostalCode, ...);
    _commandExecuter.Execute(clientMovingCommand);
}

• Универсальная служба, которая принимает объект Command (вместо DTO) и выполняет его:

// ... in remote facade or client code ...

var orderActivationCommand = new OrderActivationCommand(orderID);
_commandService.ExecuteCommand(orderActivationCommand);

// ... in application layer (service) ...

public void ExecuteCommand(Command command)
{
    _commandExeuter.Execute(command);
}