Event Sourcing, CQRS, DDD: One-to-Many relationship

Question

I am new to Event sourcing with CQRS. I am trying to define what will be the aggregate roots of my program. Lets say I have these 2 entities: Car and Person. And one invariant: a car can only be owned by one Person.

It is basically a 1-TO-M association between Person and Car

And I have this three commands:

1. Repaint a car (Only car id is given)

2. Change car owner (Car id and new Person id is given)

3. Repaint all cars owned by a Person (only person id is given)

If I use Car as an AR, the command #1 is quick to run. I will push a CarRepaint event. Command #2 is also quick to run (push CarIsOwnedBy event) But the problem occurs for command #3, I need to go through all events in the store to get each Car owned by a specific Person. The invariant is also easy to implements.

If I use Person as an AR, the command #3 is quick to run. I will push CarRepaint event for each car associated with the person. But the problem occurs for command #1, #2, I will need to go look at all events in the store to find the good car. I also have problem making sure the invariant stays true.

Am I approching the problem in the wrong way?

Thanks for your help

Answer 1

Am I approching the problem in the wrong way?

No. You might not be done yet, but the approach so far is sound.

The first thing to check is whether this model is the authority for Cars, or if it is simply recording data from some other authority (like the real world). IF the real world is the authority, then you need to be thinking in events, rather than commands; the domain model should not be trying to veto evidence from the real world.

But assuming for the moment that the model is the authority, the next things to look at are your failure mode (in my experience, focusing on the happy path tells you little about how to organize your model). What's supposed to happen if one of the four cars refuses to be painted? Do you not paint them? Do you unpaint them again? do you leave them alone?

Another thing that you may want to consider is whether the ambiguity of "all cars" is something that should be supported by the model. If the model is the book of record for a collection of cars, then the model can change that collection while the command is in flight. So maybe all cars isn't the right spelling. All cars as of a particular moment in time is immutable, but maybe still vague. All cars in this provided list is explicit.

You should also consider whether you are describing a command (a single all or nothing transaction) or a process (coordinating multiple commands). It might be that the operator is just starting a process to paint the cars, and the model does the orchestration, sending the appropriate commands to each car in the collection.