Bank account reactive DDD DEMO

This is the DDD reactive implementation of bank account example. The purpose of this demo is to demonstrate how to deal with data consistency in the reactive implementation using DDD (domain driven design) principles.

List of design patterns used in this demo

• DDD
• message driven architecture
• event sourcing
• CQRS

Technologies

This demo is implemented using:

• Spring Boot
• Project Reactor (reactive streams implementation)
• Java 17
• Gradle for build management
• Jackson for JSON serialization
• Immutables for immutable domain objects

The implementation consists of two aggregates

• Account
• Transaction

Those two aggregate roots representing two bounded contexts Account bounded context and Transaction bounded context.

Supported operations by Account aggregate

account-domain-api module contains the definition of the contract provided by Account aggregate. Here is the list of basic operations:

• create account
• deposit money
• withdraw money

HTTP API

The application exposes a RESTful HTTP API through the account-http-api module using Spring WebFlux. Available endpoints include:

• POST /accounts - Create a new account
• GET /accounts/{id} - Get account by ID
• GET /accounts - Get all accounts
• PUT /accounts/moneys/deposit - Deposit money to account
• PUT /accounts/moneys/withdraw - Withdraw money from account

An Insomnia HTTP collection (Insomnia_http_demo.json) is provided in the root directory for testing the API endpoints.

Supported operations by Transaction aggregate

transaction-domain-api module contains the definition of the contract provided by Transaction aggregate Here is the list of basic operations:

• create transaction
• cancel/rollback transaction
• finish transaction
• transfer money between two accounts

Persistence

The implementation follows CQRS and event sourcing design pattern. Persistence API is provided by common-persistence-api. This module provides in-memory storage for:

• events generated by particular aggregate AggregateRepositoryImpl
• storage for view model ViewRepositoryImpl

Note: The persistence layer uses in-memory storage for demonstration purposes only. Data is not persisted between application restarts.

Business case demonstrating data consistency

• Create two accounts A and B with a specific amount of money
• Create a transaction for transferring a specific amount of money from account A to account B
• Transaction finishes: successfully or failed

Transaction is successful

• Transaction is closed and returns the result.

Transaction failed:

Failed because account A doesn't have enough funds

• Transaction is closed and returns the result.

Failed because account B doesn't exist

• Transaction returns money to account A
• Transaction is closed and returns the result.

Failed due to cancellation

• If money was withdrawn from account A, the money is returned to account A
• Transaction is closed and returns the cancellation result.