Domain-Driven Design Terminologies Cheat Sheet (DRAFT) by [deleted]

A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. A set of consis­tency rules applies within the aggregate's bounda­ries.

A group of concepts that represents a common constr­uction in business modeling. It may be relevant only to one domain or may span many domains.

A statement of the correct state of a program at some point, indepe­ndent of how it does it. Typically, an assertion specifies the result of an operation of an invariant of a design element.

The delimited applic­ability of a particular model. Bounding Contexts gives team members a clear and shared unders­tanding of what has to be consistent and what can develop indepe­nde­ntly.

A program element that is calling the element under design, using its capabi­lities.

Logical agreement and dependence

(a.k.a. modifier) An operation that effects some change to the system (for example, setting a variable). An operation that intent­ionally creates a side effect.

An underlying consis­tency of the domain itself, which, if reflected in a model, can help the design accomm­odate change more naturally.

The setting in which a word or statement appears that determines its meaning. See Bounded Context.

A repres­ent­ation of the Bounded Contexts involved in a project and the actual relati­onships between them and their models.

The distin­ctive part of the model, central to the user's goals, that differ­ent­iates the applic­ation and makes it valuable.

A form of progra­mming in which a precise descri­ption of properties actually controls the software. An executable specif­ica­tion.

An incisive expression of the primary concerns of the domain experts and their most relevant knowledge. A deep model sloughs off superf­icial aspects of the domain and naive interp­ret­ations.

A descri­ption of commun­icating objects and classes that are customized to solve a general design problem in a particular context.

A process of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful. In software design, the abstra­ction of key aspects in a model, or the partit­ioning of a larger system to bring the Core Domain to the fore.

A sphere of knowledge, influence or activity.

A member of a software project whose field is the domain of the applic­ation, rather than software develo­pment. Not just any user of the software, the domain expert has deep knowledge of the subject.

That portion of the design and implem­ent­ation respon­sible for domain logic within a Layered Archit­ecture. The domain layer is where the software expression of the domain model lives.

An object fundam­entally defined not by its attrib­utes, but by a thread of continuity and identity.

A mechanism for encaps­ulating complex creation logic and abstra­cting the type of a created object for the sake of a client.

An operation that computes and returns a result without observable side effects.

The property of never changing observable state after creation.

A concept that is necessary to understand the meaning of a model or design but is never mentioned.

A design in which the names of classes, methods and other elements convey both the original develo­per's purpose in creating them and their value to a client developer.

An Assertion about some design element that must be true at all times, except during specif­ically transient situations such as the middle of the execution of a method, or the middle of an uncomm­itted database transa­ction.

A process in which a program is repeatedly improved in small steps. Also, one of those steps.

A set of high-level concepts, rules or both that establ­ishes a pattern of design for an entire system. A language that allows the system to be discussed and understood in broad strokes.

A technique for separating the concerns of a software system, isolating a domain layer, among other things.

A sequence of states an object can take on between creation and deletion, typically with constr­aints to ensure integrity when changing from one state to another. May include migration of an Entity between systems and different Bounded Contexts.

A system of abstra­ctions that describes selected aspects of a domain and can be used to solve problems related to that domain.

A design in which some subset of software elements corres­ponds closely to elements of a model. Also, a process of co-dev­eloping a model and an implem­ent­ation that stay aligned with each other.

A particular style of carving out concepts in a domain, combined with tools to create software analogs of those concepts (for example, object­-or­iented progra­mming and logic progra­mming).

A mechanism for encaps­ulating storage, retrieval and search behavior which emulates a collection of objects.

An obligation to perform a task or know inform­ation.

An operation offered as an interface that stands alone in the model, with no encaps­ulated state.

Any observable change of state resulting from an operation, whether intent­ional or not, even a deliberate update.

See function.

A class that can be understood and tested without reference to any others, except system primitives and basic libraries.

The property of a design element that allows a client to use any of its operations without regard to the element's history. A stateless element may use inform­ation that is accessible globally and may even change that global inform­ation (that is, it may have side effects) but holds no private state that affects its behavior.

Modeling and design decisions that apply to large parts of the system. Such decisions affect the entire project and have to be decided at team level.

A design that puts the power inherent in a deep model into the hands of a client developer to make clear, flexible expres­sions that give expected results robustly. Equally important, it leverages that same deep model to make the design itself easy for the implem­enter to mold and reshape to accomm­odate new insight.

A language structured around the domain model and used by all team members to connect all the activities of the team with the software.

The internal consis­tency of a model such that each term is unambi­guous and no rules contra­dict.

An object that describes some charac­ter­istic or attribute but carries no concept of identity.

An object that models a single, complete concept.