Show Menu
Cheatography

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

A description of the most common terminologies within domain-driven design.

This is a draft cheat sheet. It is a work in progress and is not finished yet.

AGGREGATE

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 aggr­ega­te, designated as the root. A set of consis­tency rules applies within the aggr­ega­te's bounda­ries.

ANALYSIS PATTERN

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.

ASSERTION

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

BOUNDED CONTEXT

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.

CLIENT

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

COHESION

Logical agreement and dependence

COMMAND

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

CONCEPTUAL CONTOUR

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

CONTEXT

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

CONTEXT MAP

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

CORE DOMAIN

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

DECLAR­ATIVE DESIGN

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

DEEP MODEL

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.

DESIGN PATTERN

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

DISTIL­LATION

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.
 

DOMAIN

A sphere of knowledge, influence or activity.

DOMAIN EXPERT

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.

DOMAIN LAYAER

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

ENTITY

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

FACTORY

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

FUNCTION

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

IMMUTABLE

The property of never changing observable state after creation.

IMPLICIT CONCEPT

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

INTENT­ION­-RE­VEALING INTERFACE

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.

INVARIANT

An Asse­rtion 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.

ITERATION

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

LARGE-­SCALE STRUCTURE

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.

LAYERED ARCHIT­ECTURE

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

LIFE CYCLE

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 Contex­ts.

MODEL

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

MODEL-­DRIVEN DESIGN

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.

MODELING PARADIGM

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).

RERPOS­ITORY

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

RESPON­SIB­ILITY

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

SERVICE

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

SIDE EFFECT

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

SIDE-E­FFE­CT-FREE FUNCTIONS

See func­tion.

STANDALONE CLASS

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

STATELESS

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.

STRATEGIC DESIGN

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.

SUPPLE DESIGN

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.

UBIQUITOUS LANGUAGE

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

UNIFIC­ATION

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

VALUE OBJECT

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

WHOLE VALUE

An object that models a single, complete concept.
           

Support Cheatography!