Skip to content

Latest commit

 

History

History
80 lines (53 loc) · 4.61 KB

README.md

File metadata and controls

80 lines (53 loc) · 4.61 KB

ddd-leaven-akka-v2Build Status

Join Akka-DDD chat at https://gitter.im/pawelkaczor/akka-ddd

Sample e-commerce application built on top of Akka and EventStore following a CQRS/DDDD-based approach.

Overview

This sample e-commerce system has unique set of properties. It is:

  • responsive, resilient, elastic 👏,
  • incorporates a SOA, EDA, and Microservice architecture 👌,
  • incorporates CQRS/DDDD architectural patterns 👍,
  • supporting long-running business processes (eg. payment deadlines) 💪, and
  • developer-friendly (implemented in Scala, ~1500 lines of code) 😄.

All these capabilities are obviously supported by the underlying technology stack, which includes:

  • Akka - actor-based, reactive middleware implemented in Scala,

  • Akka HTTP - HTTP server build upon Akka Stream (Akka's implementation of Reactive Streams Specification),

  • Akka Persistence - infrastructure for building durable (event sourced) actors, which has a pluggable journal,

  • Event Store - scalable, highly available event store with akka-persistence journal implementation. Provides engine for running user-defined projections (javascript functions) over single or multiple event streams. Projections allow the system to group or combine events into new event streams that can represent domain-level journals such as office journals (events grouped by emitter (Aggregate Root) class) or business process journals (events related to concrete business process). Domain journals are topic of interest for services such as:

    • view updaters - responsible for updating the read side of the system
    • receptors - allow event-driven interaction between subsystems (event choreography), including long-running processes (sagas),

❗ Both view uppdaters and receptors are operating within non-blocking back-pressured event processing pipeline ❗

  • Akka-DDD - framework containing glue-code and all building blocks

Subsystems

The system currently consists of the following subsystems:

  • Sales/Reservation - responsible for creating and confirming Reservations
  • Invoicing - responsible for the invoicing
  • Shipping - responsible for the goods delivery
  • Headquarters - executes the Ordering Process (see below)

Ordering Process

Ordering Process

Subsystem components

Each subsystem is divided into write and read side, each side containing back-end and front-end application:


write-back

Backend cluster node hosting Aggregate Roots, Receptors and Process Managers (Sagas).

write-front

HTTP server forwarding commands to backend cluster.


read-back

View update service that consumes events from event store and updates view store (PostgreSQL database).

read-front

HTTP server providing rest endpoint for accessing view store.

Running and testing the system