1

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

thomas_p
  • 97
  • 1
  • 14

1 Answers1

2

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.

  1. 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.

  1. 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.

Luca Masera
  • 672
  • 7
  • 18
  • [1/2] @LucaMasera Thank you very much for your analytical answer. I had a second look on my question earlier and also came to conclusion that splitting the eventual changes on the same entity into multiple commands is just making the situation more complex and the code harder to read. So, I decided to keep all the eventual changes in the "scope" of the same command, and only create further domain events and commands if the "change" must be propagated to another entity (outside of `Match`). – thomas_p May 12 '21 at 16:12
  • 1
    [2/2] Also, as you said, this way I make sure my business logic stays inside my domain entities and not anywhere externally, like an event or a command handler for example. Moreover, by the 3 situations you explained above, I think it could be better to refactor my Domain model and make it look more like the 2nd scenario you said (transfer `Status` property on another entity), but this is a different topic. Anyways, thank you very much once again. – thomas_p May 12 '21 at 16:13