Combating Jargon
In traditional event sourcing, there's a lot of jargon that can make it hard to even get started. In Verbs, we tried to abandon a lot of the jargon for (what we believe are) simpler and more obvious terms.
If you have event sourcing experience, or have heard event sourcing terms before, it may be useful to compare them to what we have in Verbs.
Aggregates
Aggregates (or Aggregate Roots) are called State in Verbs. Aggregate Root is technically
a great term, because they are used to aggregate your events into a single state in the same
way that aggregate functions like SUM() or MAX() in a SQL database aggregate a bunch of
rows of data into a single value.
Aggregates or States can also be thought of as reducers (like useReducer in React), in that
they take a stream of events and reduce them to a single state at a moment in time.
Projectors
In many event sourcing system, you'll have dedicated Projectors that listen for events and project data in a convenient shape for your views. These are sometimes called Projections or maybe View Models.
In Verbs, while it's possible to register dedicated Projectors, most projection is done in
the handle method of an event. For example, an AccountWasDeactivated event may project
a cancelled_at timestamp to the Account model.
Reactors
Reactors are similar to projectors, but they're meant for one-time side effects like sending
mail or making external API requests (things that you wouldn't want to happen again if you
ever replay your events). In Verbs, there is no formal concept of Reactors. Instead, you can
just wrap code that you only want to run once inside of a Verbs::unlessReplaying() check.
Write Models and Read Models + CQRS
CQRS stands for "Command Query Responsibility Segregation" and is a pattern where writes (commands) and reads (queries) are kept separate. Improved scalability and performance are often cited as reasons to introduce CQRS, but the real benefit for even small applications is the flexibility that it allows. Developers often have to make concessions in their data models to account for both read and write concerns. With event sourcing and separate read and write models, you can build Eloquent (read) models that are 100% custom-tailored to your application UI and access patterns, and create new data through events (writes) that map exactly to what happened in your application.