# Domain-Driven Design

> Ubiquitous language, domain model, bounded context, context map, entities, value objects, aggregates, repositories, domain events, strategic design.

## Concepts

- [Aggregate](https://arc.fuet.ch/concepts/domain-driven-design/aggregate.md): An aggregate is a group of related domain objects treated as one unit. One object, the root, is the only entry point from outside, and it keeps the whole group consistent.
- [Bounded Context](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context.md): A bounded context is a boundary inside which one domain model applies. Large domains split into several contexts, each with its own model and vocabulary, so no single model has to fit everything.
- [Bounded Context Canvas](https://arc.fuet.ch/concepts/domain-driven-design/bounded-context-canvas.md): The Bounded Context Canvas is a collaborative template for designing and documenting one bounded context. It captures name, purpose, importance, behavior, assumptions, and open questions.
- [Business Domain Understanding](https://arc.fuet.ch/concepts/domain-driven-design/business-domain-understanding.md): Business domain understanding means architects and stakeholders share one clear picture of the business and its terms. Where meanings truly differ, bounded contexts keep each meaning in its own place.
- [Cargo Shipping Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/cargo-shipping-domain-model-example.md): The cargo shipping model is a worked example of a domain model for booking, routing and tracking cargo. It shows how naming business concepts clearly, such as plan versus actual handling, gives a model that experts can discuss.
- [Constraining Associations](https://arc.fuet.ch/concepts/domain-driven-design/entity-relationship-clarification.md): Constraining associations means limiting how objects in a domain model can reach each other. You impose a direction or add a qualifier, so each remaining link needs less implementation.
- [Context Map](https://arc.fuet.ch/concepts/domain-driven-design/context-map.md): A context map shows how bounded contexts relate in strategic DDD. It records who provides and who consumes, using named relationship patterns. DDD has no fixed notation, so each map must explain its arrows.
- [DDD Building Blocks (Tactical Patterns)](https://arc.fuet.ch/concepts/domain-driven-design/ddd-modeling-elements.md): DDD building blocks are modeling elements: entities, value objects, aggregates, domain events, domain services and repositories. They align code with business problems and share business vocabulary.
- [Deriving System Components from the Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/deriving-system-components-from-the-domain-model.md): Building blocks can be found by studying the domain model. Concepts that belong together form a component, and cohesion guides the grouping. Parts owned by other teams are kept apart and marked as external.
- [Domain Event](https://arc.fuet.ch/concepts/domain-driven-design/domain-event.md): A domain event records something that happened in the business and that other parts of the domain need to know about. It is named in the past tense, never changes, and can trigger reactions in other aggregates or bounded contexts.
- [Domain Layer Separation](https://arc.fuet.ch/concepts/domain-driven-design/domain-layer.md): Domain layer separation keeps business logic in its own layer, apart from the user interface, the application layer, and technical infrastructure. Several front ends can then reuse the same logic.
- [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md): A domain model is a system of abstractions that describes selected aspects of a business domain. Software is built on it, and teams evolve it in code over the product's life.
- [Domain Service](https://arc.fuet.ch/concepts/domain-driven-design/domain-service.md): A domain service is a stateless object that holds business logic which does not fit naturally in one entity or value object. It often covers rules that span several entities or aggregates.
- [Domain Storytelling](https://arc.fuet.ch/concepts/domain-driven-design/domain-storytelling.md): Domain Storytelling lets domain experts describe how they work, while the group draws each story as a simple picture of actors, work objects, and activities. The drawings help business and IT people share one language.
- [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md): Domain-Driven Design (DDD) is an approach for complex business software. It organizes messy domain logic into models built in software, evolved over time, and split into bounded contexts as the domain grows.
- [Domain-Driven Design of the Data Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-modeling-procedure.md): Domain-driven design of the data model builds data structures from business knowledge. Teams use business vocabulary to find entities, value objects, aggregates and bounded contexts, and they keep refining the result.
- [Entity](https://arc.fuet.ch/concepts/domain-driven-design/entity.md): An entity is a domain object defined by its identity, not its attributes. Its attributes can change and it stays the same thing. Two objects with equal attributes can still be different entities.
- [Entity and Value Object](https://arc.fuet.ch/concepts/domain-driven-design/entity-vs-value-object.md): An entity is tracked by an identity that lasts even as its attributes change. A value object has no identity, is immutable, and equals another when all its values match.
- [Entity Life Cycle](https://arc.fuet.ch/concepts/domain-driven-design/entity-life-cycle.md): An entity life cycle is the path an entity follows over time, from the moment it gets an identity until it ends. Named, guarded transitions and invariants stop it from entering invalid states.
- [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md): Iterative domain modeling means a domain model starts simple and improves over time. The team builds it in code, learns more about the domain, and revises model and code together.
- [Module](https://arc.fuet.ch/concepts/domain-driven-design/module.md): A module groups related domain concepts so people can understand one group at a time. Choose modules by meaning, not by technical category, and give them names the whole team uses.
- [Reflecting the Business Domain in the Architecture](https://arc.fuet.ch/concepts/domain-driven-design/reflecting-the-business-domain-in-the-architecture.md): Architecture works better when it follows the business domain. Teams use the business's own words, let domain experts correct those words, and split large domains into bounded contexts instead of forcing one model.
- [Ubiquitous Language](https://arc.fuet.ch/concepts/domain-driven-design/ubiquitous-language.md): A ubiquitous language is one shared vocabulary that developers and domain experts both use. It comes from the model and is tested in conversation. Its terms hold only inside one bounded context.
- [Value Object](https://arc.fuet.ch/concepts/domain-driven-design/value-object.md): A value object is a small domain object with no identity of its own. Two value objects with the same attribute values are equal. Treat them as immutable: to change one, create a new one.