parent-child relationships, retrive child aggregate Id + invoke child update state operation

Hi,

I’m new axonframework user, using latest version 3 user, and i try to understand some basic concepts.
I have following model:

4 aggregates,
B, C and D other aggregates with following associations:

A-- * B ( A holds a Set of B aggregates)
B aggregate (@aggregateMember)

B.ID
amount
C.ID
D.ID

C aggregate
C.ID Identity

  • other fields

D aggregate
D.ID Identity
value

computeValue()

I want following workflow;

step 1- createACommand (name, creationDate) => return A.ID
step 2 createBCommand
step 2a createCcommand(…) => get C.ID
step 2b createDCommand(…) => get D.ID
step 3- createB(amount, C.ID, D.ID) -> get B.ID
step 4- addBtoA (B.ID, A.ID) -> BAddedToAEvent

step 3: a business event which will trigger D.computeValue() on D aggregate

I have 2 questions:
1- how to get back a child aggregate Identifier (such as C.ID, D.ID ) after a command completion triggered from rootAggregate A ?
can a command return an ID ? Or can i just add ID getter in each aggregate ?
2- How to navigate to D child aggregate and invoke an update operation such as D.computeValue() method call to update D’s state ?

Thanks

Hi,

it’s fine for commands to return some value. It’s recommended to do this the least possible, but (generated) identifiers are a good ‘exception’ to this rule. In fact, a constructor command handler defaults to returning the identifier of the aggregate that was created.

If you wish to interact with an aggregate, it ahould always be done through commands. This gives you the location transparency and abstractions that help you ensure your aggregates stay reasonably decoupled. It might look strange at first, but one day you’ll love us for it :wink:

You mention that you want one aggregate to interact with another. We recommend against that. Aggregates emit events, which may trigger certain components to send out commands to other aggregates (Sagas, for example, typically do this).
However, this may be an indication that you don’t have the correct aggregate boundaries. In some cases, it’s better to use larger, multi-entity aggregates if there is a lot of coordination between them.

Hope this helps.
Cheers,

Allard