@CommandHandlerannotated Aggregate constructor. Such commands could for example be published by a simple REST endpoint or an Event Handling Component as a reaction to a certain event. Sometimes the Domain however describes certain Entities to be created from another Entity. In this scenario it would thus be more faithful to the domain to instantiate an Aggregate from it's parent Aggregate.
Aggregate-from-Aggregate Use CaseThe most suitable scenario to create a "child" Aggregate from a "parent" Aggregate, is when the decision to create the child lies within the context of a parent Aggregate. This can for example manifest itself if the parent Aggregate contains the necessary state which can drive this child-creation decision.
ParentAggregate, that upon handling a certain command will decide to create an
ChildAggregate. To achieve this,
ParentAggregatewould look something like this:
AggregateLifecycle#createNew(Class<T>, Callable<T>)is key to instantiation another Aggregate like our
ChildAggregateas a reaction to handling a command. The first parameter to the
createNewmethod is the
Classof the Aggregate to be created. The second parameter is the factory method, which expects the outcome to be an object identical to the given type.
ChildAggregateimplementation would in this scenario resemble the following format:
ChildAggregateCreatedEventis explicitly applied to notify the
ChildAggregatewas created, as this knowledge would otherwise be enclosed in the
SomeParentCommandcommand handler of the
Creating Aggregates from Event Sourcing Handlers?Creation of a new Aggregate should be done in a command handler rather than in an event sourcing handler. The rationale behind this is that you do not want to create new child Aggregates when a parent Aggregate is sourced from its events, as this would undesirably create new child Aggregate instancesIf the
createNewmethod is however accidentally called within an event sourcing handler, an
UnsupportedOperationExceptionwill be thrown as stop gap solution.