Domain-Driven Design (DDD) defines a number of concepts that help designing software effectively, in-line with the business requirements.
"When using DDD we are on a quest for deep learning about how the business works, and then to model software based on the extent of our learning. It’s really a process of learning, experimenting, challenging, learning more, and modeling again. We need to crunch and distill knowledge in great quantities and produce a design that is effective in meeting the strategic needs of an organization."
- 'Domain-Driven Design Distilled' by Vaughn Vernon -
Event modeling
There are numerous techniques to discover a domain. Event Storming is a particularly interesting one. It is a workshop format for quickly exploring business domains, engaging both Domain Experts and Software Developers.
Event modeling adopts Event Storming sticky notes. The final piece was the UI/UX aspects to complete what more resembles a movie story board (white board - or digital white board). While Event Storming focuses in discovering the problem space, Event Modeling creates a blueprint for a solution.
Bounded contexts
DDD divides up a large system into Bounded Contexts (sub-systems: restaurant, courier, order), each of which can have a unified model - essentially a way of structuring MultipleCanonicalModels. Bounded Contexts have both unrelated concepts (such as a Restaurant only existing in a restaurant context) but also share concepts (such as restaurant-order, order and shipment).
Different contexts may have completely different models of common concepts with mechanisms to map between these concepts for integration. Several strategic DDD patterns explore alternative relationships between contexts.
Aggregates
Events are grouped by `concept` within the bounded context `swim lanes` on the event modeling diagram. It communicates Aggregates as one of the DDD tactical patterns.
An Aggregate is an entity or group of entities that is always kept in a consistent state (within a single ACID transaction). The Aggregate Root is the entity within the aggregate that is responsible for maintaining this consistent state. This makes the aggregate a prime building block for implementing a domain model.
Complex business logic often requires more than what an Aggregate with only an Aggregate Root can provide. In that case, it is important that the complexity is spread over a number of Entities (aggregate members) within the aggregate.
A Value Object is an immutable member type that is distinguishable only by the state of its properties.