In the Aggregate main page we have seen how to create an Aggregate backed by Event Sourcing. In other words, the storage method for an Event Sourced Aggregate is by replaying the events which constitute the changes on the Aggregate.
An Aggregate can however be stored as-is too. When doing so, the Repository used to save and load the Aggregate, is the GenericJpaRepository. The structure of a state-stored Aggregate is a little different from an Event Sourced Aggregate:
Since the Aggregate is stored as is, correct mapping of the entities should be taking into account.
A @CommandHandler annotated constructor, or differently put the 'command handling constructor'.
This annotation tells the framework that the given constructor is capable of handling the IssueCardCommand.
The static AggregateLifecycle#apply(Object...) may be used to publish an Event Message.
Upon calling this function the provided Objects will be published as EventMessages within the scope of the Aggregate they are applied in.
The Command Handling method will first decide whether the incoming Command is valid to handle at this point.
After the business logic has been validated, the state of the Aggregate may be adjusted
Entities within an Aggregate can listen to the events the Aggregate publishes, by defining an @EventHandler annotated method.
These methods will be invoked when an Event Message is published prior to being handled by any external handlers.
A no-arg constructor, which is required by JPA.
Failure to provide this constructor will result in an exception when loading the Aggregate.
Adjusting state in Command Handlers
Differently from Event Sourced Aggregates, State-Stored Aggregates can pair the decision making logic and state changes in a Command Handler. There are no consequences for State-Stored Aggregates in following this paradigm as there are no Event Sourcing Handlers which drive it's state.