Domain Driven Design Terms

In times of cloud computing and 12-factor apps, Eric Evan's Domain Driven Design has become quite popular. Here is my personal collection of term descriptions from DDD. You may like to read also another Internet Blog about this.

• Top Level Terms
• Mindmap
• Mindmap Terms
• More Terms

Top Level Terms

Domain	The user reality: A sphere of knowledge, influence, or activity.
Model	Software abstraction of the domain. An incomplete distillation of knowledge. See also Martin Fowler's articles about domain model and its aenemic counterpart.
Ubiquituos Language	Terms and sentences about the domain, understood by both software- and business-experts.
Context	Makes domain terms meaningful and unambiguous.
Bounded Context	Context boundary description concerning multiple models.

Mindmap

Mindmap Terms

Model-Driven Design	Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious.
Layered Architecture	Isolate the expression of the domain model and the business logic, and eliminate any dependency on infrastructure, user interface, or even application logic that is not business logic.
Entities	When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model. An entity may contain business logic for its natural responsibility when it belongs to no other entity or value object.
Value Objects	When you care only about the attributes and logic of an element of the model, classify it as a value object. Treat the value object as immutable. Don’t give a value object any identity. A value object may contain business logic for its natural responsibility when it belongs to no other entity or value object.
Domain Events	Model information about state-changing activity in the domain as a series of discrete events. Represent each event as a domain object.
Services	When a significant transformation in the domain is not a natural responsibility of an entity or value object, add an operation to the model, as a standalone interface, declared as a service. Give it a name as part of the ubiquitous language.
Aggregates	CAUTION: different from UML Aggregations! Cluster the entities and value objects into aggregates and define boundaries around each. Choose one entity to be the root of each aggregate, and allow external objects to hold references to the root only. Use aggregate boundaries to govern transactions and distribution.
Repositories	Query framework. For each type of aggregate that needs global access, create the illusion of an in-memory collection of all objects of that aggregate’s root type.
Factories	Shift the responsibility for creating instances aggregates or complex objects to a separate object.
Continuous Integration	Institute a process of merging all code and other implementation artifacts frequently, with automated tests to flag fragmentation quickly.
Context Map	To plot strategy, we need a realistic, large-scale view of model development extending across our project and others we integrate with. Identify each model in play on the project and define its bounded context. Name each bounded context, and make the names part of the ubiquitous language.
Shared Kernel	Designate, with an explicit boundary, some subset of the domain model that different teams agree to share. Within this boundary, include, along with this subset of the model, the subset of code or of the database design associated with that part of the model. This explicitly shared stuff has special status, and shouldn’t be changed without consultation with the other team.
Customer/Supplier Team	Establish a clear customer/supplier relationship between the teams, meaning downstream (dependent) priorities factor into upstream planning.
Conformist	Eliminate the complexity of translation between bounded contexts. Choosing conformity enormously simplifies integration.
Anticorruption Layer	When control or communication is not adequate to pull off a shared kernel, partner or customer/supplier relationship, translation becomes more complex. As a downstream client, create an isolating layer to provide your system with functionality of the upstream system in terms of your own domain model.
Open Host Service	Define a protocol that gives access to your bounded context subsystem as a set of services.
Published Language	The translation between the models of two bounded contexts requires a common language.
Separate Ways	If two sets of functionality have no significant relationship, declare the bounded context to have no connection to the other at all, allowing developers to find simple, specialized solutions within this small scope.
Big Ball of Mud	Parts of systems where models are mixed and boundaries are inconsistent. Do not try to apply sophisticated modeling within this context.

More Terms

Hands-on Modelers	Any technical person contributing to the model must spend some time touching the code.
Model-Driven Design (MDD)	Draw from the model the terminology used in the (program) design, and the basic assignment of responsibilities. The code becomes an expression of the model.
Intention-revealing Interfaces	Name classes and operations to describe their effect and purpose, without reference to the means by which they do what they promise. This relieves the client developer of the need to understand the internals.
Standalone Classes	Low coupling, try to reduce dependencies to other classes.
Side-Effect-Free Functions	"Pure" functions , do no perform a state change.
Commands	Change state, should not return a value (void).
Assertions	State pre- and post-conditions of operations, and invariants of classes and aggregates.
Closure of Operations	"Fluent Interface" on value objects, i.e. functions that return "this". (Taken from mathematics.)