The missing, complete example of Domain-Driven Design enterprise application backed by Spring stack
Branch: master
Clone or download
michal-michaluk Merge pull request #20 from adamkulawik/feature/add-endpoint-for-curr…
…ent-demands

New query for current demand per day introduced
Latest commit 3660ae3 Dec 21, 2018
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
adapter-commons droping maven Jun 27, 2018
app-monolith gradle build with docker fixed Nov 2, 2018
demand-forecasting-adapters new query for current demand per day introduced Nov 2, 2018
demand-forecasting-model droping maven Jun 27, 2018
gradle Added Gradle Jun 7, 2018
product-management-adapters droping maven Jun 27, 2018
production-planning-adapters droping maven Jun 27, 2018
shared-kernel-model droping maven Jun 27, 2018
shortages-prediction-adapters droping maven Jun 27, 2018
shortages-prediction-model droping maven Jun 27, 2018
.codecov.yml travis and codecov Mar 3, 2018
.gitattributes java10 compatibility Jun 27, 2018
.gitignore java10 compatibility Jun 27, 2018
.travis.yml java10 compatibility Jun 27, 2018
CODE_OF_CONDUCT.md Create CODE_OF_CONDUCT.md Mar 4, 2018
LICENSE Initial commit Dec 4, 2017
MIGRATION.md Fixed Jun 5, 2018
README.md packages fixed in README links Mar 28, 2018
build.gradle java10 compatibility Jun 27, 2018
command-query-crud.png code links added to readme Feb 18, 2018
docker-compose.yml docker-compose is back with both backend & database Mar 4, 2018
es-big-picture-cleaned.jpg domain and design in readme Dec 22, 2017
es-big-picture-original.jpg domain and design in readme Dec 22, 2017
es-design-demand-forecasting.jpg domain and design in readme Dec 22, 2017
gradle.properties java10 compatibility Jun 27, 2018
gradlew Added Gradle Jun 7, 2018
gradlew.bat Added Gradle Jun 7, 2018
hexagon.png code links added to readme Feb 18, 2018
lombok.config java10 compatibility Jun 27, 2018
manifest.yml java10 compatibility Jun 27, 2018
sc-pipelines.yml java10 compatibility Jun 27, 2018
settings.gradle java10 compatibility Jun 27, 2018

README.md

The missing, complete example of Domain-Driven Design enterprise application

Licence MIT Build Status Code Coverage

Command Query CRUD Responsibility Segregation

Not every piece of software is equally important... Not every piece will decide about company / product success or can cause not reversible negative business consequences like materialise brand risk or money loses. On the other hand scalability or non functional requirements are different for different activities in software.

To accommodate to those differences, separate architectural patterns are applied:

Command Query CRUD Responsibility Segregation

Simple Create Read Update Delete functionality are exposed with leverage of CRUD framework.

Goals of that approach:

  • fast initial development,
  • fast respond to typical changes (ex. „please add another 2 fields on UI”),
  • exposure of high quality API.

Examples in code:

Complex Commands (business processing) expressed in Domain Model which is embedded in hexagonal architecture.

Goals of that approach:

  • enable approach with implementing the Domain Model in the first place, by adding infrastructure adapters later,
  • keeping the Domain Model as simple as possible by protecting it from accidental complexity caused by technological choices or transport models from external services / contexts,
  • make the core business of application technology agnostic, enabling continues technology migration and keeping long living projects up to date with fast evolving frameworks and libraries.

Examples of Domain Model in code:

Examples of Ports in code:

Examples of Adapters in code:

Complex Query implemented as direct and simple as possible by:

  • fetching persistent read model expected by consumer, the read model is a projection of past domain event,
  • read model composed at query execution time build directly from persistent form of Domain Model,
  • mix of above: read model composed at query execution time build from pre-calculated persistent projections of domain event.

Additional complex calculations or projections can be partially delegated to the Domain Model if desired.

Goals of that approach:

  • encapsulation of the Domain Model complexity by providing (simpler) consumer driven or published language API,
  • freeing the Domain Model from exposing data for reads making the Domain Model simpler,
  • improves reads performance and enable horizontal scalability.

Examples in code:

Hexagonal Architecture

Only the most valuable part of that enterprise software is embedded in hexagonal architecture - complex business processing modeled in form of the Domain Model.

Domain Model embedded in hexagonal architecture

Application Services - providing entry point to Domain Model functionality, Application Services are ports for Primary / Driving Adapters like RESTfull endpoints.

Domain Model - Object Oriented (in that case) piece of software modeling business rules, invariants, calculations and processing variants. Thanks to hexagon can be as clean and simple as possible - separating essential complexity of pure business from accidental complexity of technical choices, free of technical and convention constraints.

Ports - contract defined by Domain Model expressing expectations from external resources (services, database or other models). Declared interfaces alongside with IN-OUT parameters are Ports for Secondary / Driven Adapters like repository implementation.

Adapters - integration of the technology (REST, database, external services, etc.) with the Domain Model. Making useful application from the Domain Model and the technology.

Implementing Domain Model in the first place

In most projects the biggest risk is lack of domain knowledge among developers. We all known Java, databases and bunch of handy frameworks, but what about: Investment Banking, Automotive Manufacturing or even e-Commerce.

Let's face the risk at first, maintain and explore domain knowledge with Model Exploration Whirlpool and build Ubiquitous Language with your executable Domain Model, Domain Stories and Specification by Examples from day one. Adding infrastructure and technology later is easy thanks to Hexagonal Architecture.

Simply starting from ZERO business knowledge through initial domain and opportunity exploration with Big Picture Event Storming: Big Picture Event Storming

after cleaning and trimming initial model to most valuable and needed areas: Big Picture Event Storming

Deep dive in Demand Forecasting sub-domain with Design Level Event Storming: Design Level Event Storming - Demand Forecasting

is excellent canvas to cooperative exploration of:

  • impacted and required actors,
  • initial / desired system boundaries,
  • actors interactions with system under design.

With use of Domain Stories and Specification by Examples it is easy to find:

  • business rules and invariants,
  • acceptance criteria,
  • estimation of Domain Model depth,
  • CRUD-suspected activities,
  • missing parts.