Sourcing::Aggregation
A marker role that identifies a class as an aggregation — the write side of CQRS. Aggregations validate commands against current state and emit events.
What It Does
This role is primarily a marker. The actual functionality is provided by Metamodel::AggregationHOW, which:
- Composes the
Sourcing::Aggregationrole into the class - Also composes
Sourcing::Projection(via the parent metaclass) - Auto-generates event-emitting methods for each handled event type
How It's Used
You never use this role directly. It's automatically composed when you declare an aggregation:
aggregation BankAccount {
has Int $.account-id is projection-id;
has Rat $.balance = 0;
method apply(AmountDeposited $e) { $!balance += $e.amount }
method apply(AmountWithdrawn $e) { $!balance -= $e.amount }
method deposit(Rat $amount) is command {
die "Amount must be positive" if $amount <= 0;
$.amount-deposited: :$amount;
}
}
Auto-Generated Methods
For each event type handled by the aggregation's apply methods, an emit method is auto-generated:
| Event Class | Generated Method |
|---|---|
AmountDeposited | $.amount-deposited(:$amount) |
AccountOpened | $.account-opened(:$initial-balance) |
These methods automatically include the aggregation's projection ID values and handle optimistic locking via the plugin.
Inheritance
Aggregations inherit from Sourcing::Projection, so they can also consume events via apply methods. The key difference is that aggregations can emit events while projections can only consume them.
See Also
- Aggregations Concept — when and why to use aggregations
- Sourcing::Projection — the read-side role
- Metaclasses — how the
aggregationkeyword works - Traits — the
is commandtrait