That’s quite an old picture you’re referring to there. In more recent versions of that picture (http://axonframework.googlecode.com/files/cqrs_architecture.jpg), you can see that this is in fact an event handler that sends out new commands. Typically, you would implement these components as a saga.
I am not sure I understand what Dennis means with his slides. But domain services are a DDD concept, described in detail by Eric Evans. A domain service is a concept which provides services containing business logic, which cannot be conceptually assigned to an entity. In CQRS, I haven’t encountered them, yet. But as with any building block, it is just a tool in the toolbox.
sometimes, you have use cases such as “when this happens in my system, I want to trigger something else in my system”. That’s when you would use an event handler that creates new commands. I have to admit that the arrow from event handler to domain is a littlebit misdirected. It should point to the command bus.
In the example I gave, an event listener would listen to “ThisHappenedInMySystemEvent”, and dispatch a “TriggerSomethingElseCommand” on the commandbus.
You would typically want to use mechanisms like this when a change in one aggregate should be reflected in another aggregate.
So they don’t really directly interact with the domain. Instead, the fire a command, which ends up in a Command Handler. That handler is the only component directly interacting with the domain objects.
Can one identify command handlers with domain services in the axon
framework?
It seems to me that command handlers can play the same role as domain
services do. On the other hand, with an other layer of indirection on
can keep the command handlers light weight.
command handlers and domain services have, in my opinion, two very distinct roles. Command handlers are infrastructural components that accept incoming command and call methods on the correct entity instances. They can best be compared to application services.
Domain Services are a full-blown component in DDD. They contain business logic that cannot be places within a specific entity, for whatever reason. They are relatively rare in most solutions (since it is a fallback building block) and I don’t really see a place for them in CQRS. Probably, in CQRS, the Saga is what comes closest to the domain services. The main difference being that saga’s have ability to deal with long running transactions. Domain services typically don’t.
Email sending and rule engines are simple examples of 'domain
services'. You can spot them since they're effectively "stateless"
across uses. If you're wiring with Spring, they're likely injected
prototype beans.
Some services can be called from the domain objects, others from
sagas. Depends what you're doing.
