This project will no longer be maintained. Please see https://github.com/rodolfodpk/myeslib2
Context
The idea is to explore a design introduced in Don’t publish Domain Events, return them! Basically, instead of having the CommandHandler with void method, the method will return a List<? extends Event>. These events and the original command will then form a UnitOfWork. This UnitOfWork is then persisted into a fairly effective (and simple) Event Store backed by a relational database. There is not any read model yet but I do plan to develop it just for the sake of the example. Tasks based UIs are out of the current scope. The communication between producer and consumer services is HTTP based but for now the endpoints are not really well polished REST services.
The sample core domain
Here is the SampleDomain. Except for the AggregateRoot class, all other classes (commands and events) are immutable. If you are wondering where are the final modifiers, take a look at @Value annotation from Project Lombok. And just in case you prefer to have InventoryItemAggregateRoot as an immutable class, you may use Lenses for Java to apply events to it.
There are tests for both InventoryItemCommandHandlerTest and InventoryItemAggregateRootTest. I'm using plain JUnit but it's worth to mention Event Sourcing helps a lot when writing BDD specifications.
The examples
There are two examples implemented:
- inventory-jdbi
- inventory-hazelcast
Both have in common the ReceiveCommandsAsJsonRoute. This route receives commands as JSON, deserialize it an then routes the command instance to the next endpoint.
In the Hazelcast implementation, HzConsumeCommandsRoute will then consume the command from the endpoint above and use the HzInventoryItemCmdProcessor to process the command and save the resulting events into the eventstore. After this, the HzConsumeCommandsRoute will enqueue the AggregateRoot's id into a queue being consumed by HzConsumeEventsRoute in order to reflect the events into the query model.
You can find more info on the wiki