How to propagate consequent changes inside the same Domain entity

Question

In a Domain Driven Design implementation with CQRS and Domain events, when a Command's handler performs a "change" on a Domain entity, and this "change" also causes more "changes" inside the same entity, should all these "changes" be performed by the same Command handler, or is it better to create and send different Commands to perform each of the consequent changes on this entity?

For example, let's say my Domain entity is a Match which has a Minute and a Status properties, and an UpdateMatchMinuteCommand handler updates the Match's Minute value by invoking a class method of the entity. But based on some business logic, inside the class method, this Minute change causes also a change on the Status property of the Match. Shall both of these changes (Minute and Status) take place inside the same class method mentioned earlier?

Or is it more appropriate for the class method, after updating the Minute value, to publish a MatchMinuteChangedDomainEvent, which in turn when handled will send an UpdateMatchStatusCommand, which in turn when handled will invoke another class method of the Match entity to update the value of the Status property?

Which of the above approaches would be more suitable to propagate consequent state changes inside the same Domain entity?

Thanks in advance

Answer 1

I have the feeling that you're going to over complicate the problem. If it's part of the root entity, why should you split the changes in multiple commands?

Reusing Match, Minute and Status, there are (I think...) 3 different situations then:

1. Examining the domain, you find out that Match contains Minute and Status.

From the analysis you've got the logic that trigger the changes in both the properties of the entity, and per design (DDD) you've put it into Match. Hence, inside the function that update Minute you code also the eventual change of Status.

2. From the analysis of the domain you find that the Match contains Minute, but not Status, that belongs to another root entity.

This is a case, with 2 entities involved, where using multiple commands is a plausible solution. You update one, generating an event; the event is handled by an handler, that builds another command, which in turn performs the other change. Maybe you do it into a single transaction, or you use a saga; whatever you think it fits your needs.

3. The domain requires the property Minute into Match, but there're no domain requirements about Status.

Here the Status property it exists, but it's not part of the domain: it could be an extra property, that is used only in the UI, or something else, an helper field, used to perform faster queries. Anyway, Status cannot be inside the entity, because it's not present into the domain.

Given that 2 and 3 are not what you've described, it remains only 1. Hence, I think that both should be changed inside the same action (or function).

A final consideration. You're going to:

• build a model of the domain based on your business rules, and
• build it following the DDD indications

That means that:

• the domain logic should (or must...) stay inside the domain object
• nothing that belongs to the domain should be 'exported' in external services, except things like SAGAs or complex interaction between root entities (not this case)

so, as I've written at the beginning of the answer:

• why do you split the domain logic, implementing it within the several object involved in this changes?

It means that wo reads the code, months later, to understand when, how and why Status changes has to go through the changes of Minute, then to the handler, checking also its code (and I suppose has some logic that, if put inside Match, would require less 'hops'), and, finally, the code that really change Status.