Event Sourcing in deeply nested Aggregates

[Holger Thiemann]

I try to keep it focused with an example:

Pre ES:

AR with:

SomeMethod(parameters)

//Validation

//Calculation

//Decision

//Change some fields

Post ES:

AR with:

SomeMethod(parameters)

//Validation

//Calculation

//Decision

//Fire one or more events

SomeEventHandlingMethod(event)

//Change some fields

This is (as far as I understood it) the basic principle and "transformation" from non ES to ES.

So far, so good.

Now I have a more complex example:

Pre ES:

AR with:

SomeMethod(parameters)

//Look Up Child Entity

//Delegate to Child Entity

ChildEntity with:

SomeMethod(parameters)

//Look Up Grandchild Entity

//Delegate to Grandchild Entity

GrandchildEntity with:

SomeMethod(parameters)

//Validation

//Calculation

//Decision

//Change some fields

Post ES:

??? What now?

Regarding only the Grandchild Level it seems to be the same case as in the first AR only example. But what about the 2 Layers above?

Does the SomeMethod of the GrandChild fire the event? Do the 2 levels up enrich it with their IDs? Do I have on every level a SomeEventHandlingMethod that delegates to the next deeper level?

Or should I break encapsulation and OO principles, lifting some of the code of the GrandChild SomeMethod up into the AR SomeMethod and only fire and handle the event there in the AR?

To the outside it has to look as if the AR is the only one that produces and consumes the events. Thats not the question. It's about the inner structure.

[ghiat....@gmail.com]

in this situation one solution is to use Module encapsulation (in C# use internal setters) and change the Grandchild method to just validate and return a result to tell the root if the change is possible or not and keep the same method.