The purpose of services in Greg Young's CQRS implementation

Question

I decided to get acquainted with a concrete CQRS implementation on the example of Greg Young's implementation

What I do not understand is what is the meaning of services here because it seems to be completely other than we used to in common three-tier pattern.

The client changes the received DTO and it creates a command which is handled by its handler which calls a method of a domain object.

Then the event is created and stored in the event store and published to syncronise the denormolized part.

I cannot find the service in this chain.

My co-worker told me that for example that if we do not want to store large data as part of a domain when we store in reports but when we need it in our domain we publish an event which returns something from the service.

But I cannot clearly form the picture in my mind.

Can anyone explain what services are supposed to do here?

Answer 1

In CQRS, basically the command handlers are what you'd call application services in non-CQRS scenarios.

Answer 2

'Services' can represent different things depending on the context you are talking about. Reading the article I believe he is using the term 'service' in the context of Domain Services which form the building blocks of DDD.

However, in CQRS you typically have a command service and query service, which in DDD context represent the Application Service Layer. But as I say, reading the article, I think his use of the word 'service' is meant for domain services.

Answer 3

When you have problems like Set Consistency Validation. For example: Set Validation Post in SO you may need a Service that ensures that incoming duplicate commands of a value that should only be persisted once are rejected. In this case, a service basically does an insert in a Sql table with a primary key constraint. It only happens once, otherwise, throws an error and the whole process fails and no events are generated, no reporting in the query side. Just a case.

Answer 4

You mean about service a remote facade (Web service) which will call application layer, because domain service is a different thing.

The remote facade layer (web service) if you are designing n-tier application to expose application services to other tiers will expose your business and commands by calling the application layer, the application layer as mentioned by David:

For Read Part, in your application layer you need to design a Query Service with methods like FindOrders(x, y, z), GetMostOrderedItems(), ...

For the Write part, you can design the command service in one of many ways like:

• Service which takes DTOs and execute domain logic based on it [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
}

• Service which takes DTOs and convert it to a Command to be executed on domain model:

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);
}

• Generic Service which takes a Command object (instead of DTO) and execute it:

// ... 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);
}