Last updated
Last updated
Aggregates are the primary objects that you will be working with.
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.
If you need to create an Aggregate ID Class in order to use type-hinting, just extend the AbstractAggregateId
class.
!!! 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.
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.
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.
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.
When you create an 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.