How Occurrent is layered
Occurrent is built in layers. Each layer is built from the one below it, and you can use any of them directly. You don’t have to pick one layer for the whole application. A projection can read CloudEvents straight from a subscription while the rest of the application works with domain events.
| Layer | Your code works with | Main parts |
|---|---|---|
| 0: CloudEvents | CloudEvent | EventStore, subscriptions, event store queries |
| 1: Domain events | Your own domain event types | CloudEventConverter, ApplicationService, DomainEventQueries, Subscriptions, views and projections, snapshots, sagas |
| 2: Spring Boot | Annotations and configuration properties | The Spring Boot starter, and annotations such as @Subscription, @Projection and @Saga |
| 3: Your own framework (experimental) | Whatever your framework exposes | Built from layer 1 parts |
Layer 0 is where everything is a CloudEvent. The event store reads and writes CloudEvents, and subscriptions deliver them. Nothing at this layer knows about your domain events. Use it directly when you want full control over how events are represented, or when you write infrastructure such as a forwarder or an audit log that should work for any event.
Layer 1 adds a CloudEventConverter, which maps your domain events to CloudEvents and back. The ApplicationService uses it to load a stream as domain events, call your domain function, and write the new events back. The other parts at this layer, such as DomainEventQueries, Subscriptions, projections and sagas, also work with domain events and use the converter underneath. Most applications should start here.
Layer 2 is Spring Boot support. The starter wires up the event store, a subscription model and a converter for you, and annotations such as @Subscription, @Projection and @Saga register handlers without any wiring code. It is more convenient, but more happens behind your back. The annotations are built on the layer 1 API, so you can drop down a layer when you need more control. Everything Spring Boot adds lives in the Spring Boot section. The layer 0 and layer 1 pages show code that runs without it, and end with a short note when a feature has a Spring Boot form.
Layer 3 is a framework built from layer 1 parts, shaped after your own business. Occurrent doesn’t ship a finished one. See Building Your Own Framework.
Some things are not part of a layer:
- Your domain model. Commands, events, state and deciders have no dependency on Occurrent at all. See Your Domain Model.
- The storage and the programming model. Each layer comes for several stores (MongoDB through the native driver or Spring Data, in-memory) and in a blocking and a reactive (Project Reactor) flavor. A Spring Data MongoDB event store is still layer 0. It uses Spring as a library, which is not the same as the Spring Boot support in layer 2.
- Dynamic Consistency Boundary (DCB). It is a capability of the event store that the other layers build on. The
DcbEventStoreis layer 0, the DCB application service and deciders are layer 1, and@DcbSubscriptionis layer 2. - Infrastructure that everything uses, such as retry and deadlines.
Where to start:
- With Spring Boot, start with Getting started with Spring Boot and read about the layer 1 parts as you use them.
- Without Spring Boot, start with a CloudEventConverter and the ApplicationService. Getting Started walks through it.
- Use layer 0 directly when you need control over the CloudEvents themselves, or when you write your own component on top of the event store.