Aggregates
Aggregates are the primary objects that you will be working with.
Aggregate ID
Each Aggregate will need to have it's own unique ID. You can use the same AggregateId class for all your aggregates or you can make you own for each one to ensure data consistency.
Working with an Aggregate ID
If you need to create an Aggregate ID Class in order to use type-hinting, just extend the AbstractAggregateId
class.
Auto Generate Aggregate IDs
!!! attention This requires the installation of the sonsofphp/event-sourcing-symfony
package.
Creating your own implementation to generate UUIDs or other type of IDs can be a pain in the ass. Once the sonsofphp/event-sourcing-symfony
package is installed, you can easily use Symfony's Uid Component to generate UUIDs for you.
Aggregate Version
An Aggregate also has a version. Each event that is raised will increase the version. You will generally not have to work much with versions as they are mostly handled internally.
Working with an Aggregate Version
Creating an Aggregate
Pretty simple to create an aggregate.
Using the AbstractAggregate
class takes care of all the heavy lifting. This allows you to focus on the different methods.
Working with Event Messages
When you create an Event Message you will need to raise that event within your aggregate and if need be, apply that event to the aggregate. Let me show you what I mean.
This is a very simplistic example. We should be doing a few checks on the email before the event is raised. What happens if we try to set an email and it's the same email as the user currently has? It would continue to raise an event.
You will also notice the applyEmailUpdated
method on the class. This is optional, but when you raise an event, the AbstractAggregate
will look for a method in the format of apply{EventMessageClassname}
. So if the event classname was DrankABeer
it would look for the method applyDrankABeer
and if there is one, it will pass in the DrankABeer
event message.
Last updated