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:
Simple Create Read Update Delete functionality are exposed with leverage of CRUD framework.
Goals of that approach:
Examples in code:
Complex Commands (business processing) expressed in Domain Model which is embedded in hexagonal architecture.
Goals of that approach:
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:
Additional complex calculations or projections can be partially delegated to the Domain Model if desired.
Goals of that approach:
Examples in code:
Only the most valuable part of that enterprise software is embedded in hexagonal architecture - complex business processing modeled in form of the Domain Model.
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.
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:
after cleaning and trimming initial model to most valuable and needed areas:
Deep dive in Demand Forecasting sub-domain with Design Level Event Storming:
is excellent canvas to cooperative exploration of:
With use of Domain Stories and Specification by Examples it is easy to find:
