digital-restaurant

DDD. Event sourcing. CQRS. REST. Modular. Microservices. Kotlin. Spring. Axon platform. Apache Kafka. RabbitMQ

View the Project on GitHub idugalic/digital-restaurant

projects/digital-restaurant Build Status GitPitch

‘d-restaurant’ is an example of an application that is built using Event Sourcing and CQRS. The application is written in Kotlin, and uses Spring Boot. It is built using Axon, which is end-to-end development and infrastructure platform for smoothly evolving event-driven microservices focused on CQRS and Event Sourcing patterns.

Customers use the website application to place food orders at local restaurants. Application coordinates a network of couriers who deliver the orders.

Table of Contents

Domain

This layer contains information about the domain. This is the heart of the business software. The state of business objects is held here.

Business capabilities of ‘Digital Restaurant’ include:

As you try to model a larger domain, it gets progressively harder to build a single unified model for the entire enterprise. In such a model, there would be, for example, a single definition of each business entity such as customer, order etc. The problem with this kind of modeling is that:

Domain-driven design (DDD) avoids these problems by defining a separate domain model for each subdomain/component.

Subdomains are identified using the same approach as identifying business capabilities: analyze the business and identify the different areas of expertise. The end result is very likely to be subdomains that are similar to the business capabilities. Each sub-domain model belongs to exactly one bounded context.

Core subdomains

Some sub-domains are more important to the business then others. This are the subdomains that you want your most experienced people working on. Those are core subdomains:

The Order (RestaurantOrder, CustomerOrder, CourierOrder) aggregate class in each subdomain model represent different term of the same ‘Order’ business concept.

Event sourcing

We use event sourcing to persist our event sourced aggregates as a sequence of events. Each event represents a state change of the aggregate. An application rebuild the current state of an aggregate by replaying the events.

Event sourcing has several important benefits:

Event sourcing also has drawbacks:

Consider using event sourcing within ‘core subdomain’ only!

Snapshoting

By use of evensourcing pattern the application rebuild the current state of an aggregate by replaying the events. This can be bad for performances if you have a long living aggregate that is replayed by big amount of events.

Each aggregate defines a snapshot trigger:

Generic subdomains

Other subdomains facilitate the business, but are not core to the business. In general, these types of pieces can be purchased from a vendor or outsourced. Those are generic subdomains:

Event sourcing is probably not needed within your ‘generic subdomain’.

As Eric puts it into numbers, the ‘core domain’ should deliver about 20% of the total value of the entire system, be about 5% of the code base, and take about 80% of the effort.

Organisation vs encapsulation

When you make all types in your application public, the packages are simply an organisation mechanism (a grouping, like folders) rather than being used for encapsulation. Since public types can be used from anywhere in a codebase, you can effectively ignore the packages.

The way Java types are placed into packages (components) can actually make a huge difference to how accessible (or inaccessible) those types can be when Java’s access modifiers are applied appropriately. Bundling the types into a smaller number of packages allows for something a little more radical. Since there are fewer inter-package dependencies, you can start to restrict the access modifiers. Kotlin language doesn’t have ‘package’ modifier as Java has. It has ‘internal’ modifier which restricts accessiblity of the class to the whole module (compile unit, jar file…) which can hold many packages.

The goal (maybe it is a rule) is to bundle all of the functionality related to a single component into a single Java/Kotlin package, and restrict accessiblity of the classes to package, were possible. For example, our Customer component classes are placed in one com.drestaurant.customer.domain package, with all classes marked as ‘internal’. Public classes are placed in com.drestaurant.customer.domain.api and they are forming an API for this component. This API consist of commands and events. As we have one maven module holding one package/component we are using Kotlin internal modifier as an encapsulation mechanism on the package level as well. This rule is handled by the compiler, which is good, and we can achieve loose coupling and high cohesion effectively.

If you prefer to organize more packages/components into one maven module (maybe use single maven module for all components, and not multi maven module by component as we have now) you should use different encapsulation mechanism because Kotlin is lacking of package modifier.

We use an ArchUnit test to force ‘package’ scope of the Kotlin classes. This rule is handled on the Unit test level, which is not perfect, but still valuable.

Context Mapping

Bounded contexts (and teams that produce them) can be in different relationships:

You may be wondering how Domain Events can be consumed by another Bounded Context and not force that consuming Bounded Context into a Conformist relationship.

Consumers should not use the event types (e.g., classes) of an event publisher. Rather, they should depend only on the schema of the events, that is, their Published Language. This generally means that if the events are published as JSON, or perhaps a more economical object format, the consumer should consume the events by parsing them to obtain their data attributes. This rise complexity (consider consumer driven contracts testing), but enables loose coupling.

Our demo application demonstrate conformist pattern, as we are using strongly typed events.

As our application evolve from monolithic to microservices we should consider diverging from conformist and converging to customer-supplier bounded context relationship depending only on the schema of the events (with consumer driven contracts included).

Applications

We have created more ‘web’ applications (standalone Spring Boot applications) to demonstrate the use of different architectural styles, API designs (adapters) and deployment strategies by utilizing components from the domain layer in different way.

This is a thin layer of adapters that surrounds our domain layer, and exposes it to the outside world. It does not contain business logic. It does not hold the state of the business objects.

Our Driving Adapters are mostly Controllers (REST and/or WebSockets) who are injected in their constructor with the concrete implementation of the interface (port) from the Domain layer. These interfaces (ports) and their implementations are provided by Axon platform:

Adapters are adapting the HTTP and/or WebSocket interfaces to the domain interfaces (ports) by converting requests to messages/domain API (commands, queries) and publishing them on the bus.

Our Driven Adapters are implementations of domain interfaces (ports) that are responsible for persisting (e.g event sourced aggregates), publishing and handling domain events. Event handlers are creating read only projections that are persisted in JPA repositories, forming the query (read) side. These interfaces (ports) and their implementations are provided by Axon platform

Monolithic

Microservices (decomposed monoliths)

Monorepo

We have one deployment pipeline for all applications and libraries within this repository. In addition, all projects in the repository share the same dependencies. Hence, there are no version conflicts because everyone has to use the same/the latest (SNAPSHOTS) version. And you don’t need to deal with a private NPM (JavaScript) or Maven (Java) registry when you just want to use your own libraries. This setup and project structure is usually addressed as a monorepo.

Technology

Language

Frameworks and Platforms

Continuous Integration and Delivery

Infrastructure and Platform (As A Service)

References and further reading


Created by Ivan Dugalic