1

I'm new to CQRS and need advice on the following situation in my design. A command updates state of an aggregate A; the read model needs to be consequently updated with a result of a cross-aggregate calculation method; this method belongs to another aggregate B which holds a reference to the aggregate A; the method is a function of states of both aggregate B and the referenced aggregate A. Where is the correct place for this function to be called?

My considerations (can be skipped):

  • Command handler updating state of aggregate A could technically fetch aggregate B from the repository, call calculation on it and put result in the domain event; however I believe it's not command handler's job to fetch aggregates other than one being modified, even for reading purposes; also it's not command handler's job to perform calculations just to send with events rather than modify the state of domain.
  • The domain event ('Aggregate A updated') raised by the aggregate A contains only updated state of aggregate A, there's not enough info on state of aggregate B. Read model's event handler has no access to domain model, so it can neither fetch aggregate B nor call the desired function on aggregate B to update read model.
  • I know that any state needed by command which is external to the aggregate being modified must be passed along with the command. This way the application service, before sending the command, could fetch state of aggregate B (from read model), and put it in the command. For that I would have to move the function from aggregate B to some service and pass there states of both A and B. That would make aggregate B more anemic. Plus the above mentioned problem with doing calculations within command handler.
  • I've read people suggesting that any calculations that only read model is interested in belong to the read model itself. So the read model's handler of my event would just have at its disposal all needed state and behavior to perform calculations. However that would mean I have to duplicate much of the domain model concepts at the query side; it would be too complex to have a full-blown read model.

I've just thought of the following solution: within the domain, create a handler of the domain event 'Aggregate A updated'. It would fetch aggregate B, call the calculation method on it, then raise an 'Aggregate B function result changed' event with the new calculation result in it. Then the read model is able to take the result from this event and update itself. Would this be ok?

Note just in case that I'm not using Event Sourcing.

Any thoughts on this situation would be much appreciated. Thanks!

UPDATE: making the situation more concrete

My aggregates are Workers (Aggregate B) and Groups of workers (Aggregate B). Workers and Groups are a many-to-many relationship. Imagine both a Group and a Worker have some Value property. Worker's calculateValue() is a function of the Worker's Value plus Values of all Groups the Worker participates in. The Command described above is modifying Value for some Group. As a result, all Workers participating in the group would return different result of calculateValue().

What do I want from the read model? I want a list of Workers with calculated Values (that already account for Values from the Worker's all groups). I don't even need Group at the read side. If I go the 'do calculation on the read side' way, I need Groups as well as the whole structure of relationships there. I'm afraid it would be an unjustified complication.

Pavel S.
  • 1,202
  • 1
  • 13
  • 29
  • How can you not need Group at the read side? In the UI, without a read side, how do you know what Groups are available, e.g. to add a Worker to? And how can you update the 'Value' for a Group if you can't query a Group to show it to the user? – TomW Sep 13 '17 at 13:26
  • Also, remember aggregates cannot reference other aggregates, only their IDs. In any case, with CQRS, referencing an aggregate object would be useless in any case, since it has no read methods (aggregates are write-only objects). – TomW Sep 13 '17 at 13:31
  • @TomW The read model I'm talking about is not to be used by the UI that edits Workers and Groups relationships. My understanding is that you can have many read models, can't you? This model is rather to be used be a client component that only needs Workers and calculated values on them. – Pavel S. Sep 13 '17 at 13:31
  • @TomW Yes, I reference aggregates by natural IDs. I could use injected repo to fetch a referenced aggregate. So you are saying I cannot use reference to another aggregate in some logic? Only `getAnotherAggregateID()` method allowed? – Pavel S. Sep 13 '17 at 13:38
  • 1
    Yes, multiple read models are fine. While it's best to decouple read models, it's permissible for one read model to query another when it applies an event, if that other read model already has the data it needs - it's a trade off between repetition and decoupling, but can also cause ordering issues (if you need to wait for the other read model to catch up - you might need to poll). Does the existing Group read model have the calculated value you're after? Would it be easier to add it there? – TomW Sep 13 '17 at 13:43
  • "I could use injected repo to fetch a referenced aggregate" - You cannot query the Aggregate, you fetch it for nothing. – Constantin Galbenu Sep 13 '17 at 14:21
  • @TomW Thanks for your remarks. I've got some impulse towards reconsidering the whole model and better understanding of CQRS principles. – Pavel S. Sep 13 '17 at 17:24

1 Answers1

2

Command handler updating state of aggregate A could technically fetch aggregate B from the repository, call calculation on it and put result in the domain event; however I believe it's not command handler's job to fetch aggregates other than one being modified, even for reading purposes; also it's not command handler's job to perform calculations just to send with events rather than modify the state of domain.

This is not OK because events should represent facts that happened in regard to a single Aggregate.

I know that any state needed by command which is external to the aggregate being modified must be passed along with the command. This way the application service, before sending the command, could fetch state of aggregate B (from read model), and put it in the command. For that I would have to move the function from aggregate B to some service and pass there states of both A and B. That would make aggregate B more anemic. Plus the above mentioned problem with doing calculations within command handler.

You should not send the Aggregate state in an event. In fact you should not query the Aggregate or use it't internal and private state in any other way but by the Aggregate itself. In CQRS the Aggregate is not to be queried. That's a read-model's purpose.

I've read people suggesting that any calculations that only read model is interested in belong to the read model itself. So the read model's handler of my event would just have at its disposal all needed state and behavior to perform calculations. However that would mean I have to duplicate much of the domain model concepts at the query side; it would be too complex to have a full-blown read model.

This is the way to go. However, what do you duplicate anyway? Is the result of that calculation used by the Aggregate to accept or reject any of its commands?

If yes, then it should be done inside the Aggregate, at command execution time and possible the final result sent along the event but only if the calculation can be done with the data from the command and/or the internal Aggregate's state and not by cross Aggregates state. If an Aggregate needs data from other Aggregates then that is a sign that your Aggregates boundaries might be wrong.

If not then the calculation should not stay inside the Aggregate, but only in the read-model.

In CQRS, by splitting the Write from the Read model you would split the calculations also to Write and to Read but there are some cases where a calculation is shared by the two models. In these cases you can extract the calculation inside a Class and use that Class in both the models.

Constantin Galbenu
  • 16,951
  • 3
  • 38
  • 54
  • Thank you for your reply! The answer to your question '_Is the result of that calculation used by the Aggregate to accept or reject any of its commands?_' is '_no_'. I've updated my question where I expanded on my case by specifying concrete aggregates and relations between them. I still think it would be too hard to go the way you recommend, even though I believe it is conceptually correct. Looking forward to your opinion again. – Pavel S. Sep 13 '17 at 13:20
  • @PavelS your use case is still to general, you need to be more specific. In fact we need the exact calculation and what you do with it and where (read, write side). – Constantin Galbenu Sep 13 '17 at 14:23
  • Now I guess I've had some shift in my understanding after @TomW's and your remarks on aggregate being inappropriate for querying. I was probably hoping for some half-hearted solutions, but now I see CQRS is an uncompromising thing :) Will have to reexamine the whole design. Thank you again. – Pavel S. Sep 13 '17 at 17:17