A Domain Concept is the fundamental building block of a domain model. It represents a meaningful, named thing that domain experts recognize and reason about -not a database table or a service class, but a real-world idea the business depends on.

Name

Explanation: The name of a concept is its primary handle. It must be a ubiquitous term that domain experts naturally use in conversation. According to concept design principles, names are essential because they allow teams to refer to known patterns without having to constantly explain them. A good name should be generic enough to capture the essence of the concept without getting bogged down in application-specific jargon.

Example:

  • Good: Trash or Reservation. These are immediately recognizable and evoke a clear mental model.
  • Bad: DeletedItemsTemporaryStorage or ResourceBookingManager. These are tech-heavy, implementation-focused, and not how real people speak.

Definition & Purpose

Explanation: The purpose explains why the concept exists and what fundamental human or business need it fulfills. A well-defined purpose justifies the cost of designing and implementing the concept. The purpose must be cogent, need-focused, specific, and evaluable. It should not just describe how a feature works, but the overarching objective it achieves. If you cannot identify a compelling purpose, the concept might be a redundant technical mechanism rather than a true domain concept.

Example:

  • Reservation: The purpose is to “manage efficient use of resources”.
  • Trash: The purpose is “to allow undoing of deletions” (not simply “to delete files”, which is an action, not the underlying need).

Identity

Explanation: Identity dictates how we distinguish one instance of a concept from another over time, regardless of how its internal data changes. In DDD terms, this determines whether a concept is an Entity (has a persistent identity) or a Value Object (identified only by its attributes). Identity is crucial for tracking the lifecycle of an object as it mutates.

Example:

  • User: Identified by an immutable, unique EmailAddress or a system-generated UUID. Even if the user changes their display name or password, their identity remains the same.
  • Color Theme (Value Object): A style setting like “Dark Mode” has no lifecycle or unique ID. If its attributes are the same as another “Dark Mode”, they are completely interchangeable.

Key Attributes

Explanation: Key attributes represent the State of the concept -the memory it requires to function. A concept’s data model should be localized and contain only what is strictly necessary to support its behavior. If an attribute does not participate in a business rule or a concept action, it likely does not belong in the domain model and is merely UI-level metadata.

Example:

  • Reservation State: Needs to remember available resources (a set of unbooked resources) and reservations (a mapping linking a specific User to a specific Resource).
  • Incidental data like the user’s UI theme preference or the timestamp of when they clicked the button are excluded because they do not drive the domain logic.

Behavior & Lifecycle

Explanation: Behavior defines the Actions that mutate the concept’s state. A concept is fundamentally defined by its dynamics; as a rule of thumb, if there is no behavior, there is no concept. Actions are instantaneous events that take inputs, apply business rules, and transition the concept into a new state. Documenting the lifecycle means defining how an instance is created, how it mutates, and how it is ultimately resolved or destroyed.

Example:

  • Reservation Actions: The lifecycle includes provide (adding a resource to the available pool), reserve (associating a user with a resource and removing it from availability), use (consuming the reserved resource), and cancel (freeing the resource back to the available pool).

Scenarios & Examples

Explanation: Scenarios describe the “Operational Principle” of the concept -an archetypal sequence of actions demonstrating exactly how the concept fulfills its purpose. Instead of just listing features, an operational principle acts as a narrative or a theorem that users and developers can rely on to understand the intended workflow.

Example:

  • Trash Scenario: “After you delete an item, you can restore it, and then the item is accessible again”.
  • Style Scenario: “If you define a style, assign it to multiple paragraphs, and then redefine the style’s formatting, all assigned paragraphs automatically update to the new format”.

Invariants & Rules

Explanation: Invariants are the constraints and preconditions that protect the integrity of the concept. A precondition dictates the strict state requirements that must be true before an action can execute. An invariant is a property that is always guaranteed to be true after an action completes successfully.

Example:

  • Precondition: A reserve action can only execute when the requested resource is currently in the available set.
  • Invariant: A single physical resource cannot be mapped to two different users for the exact same time slot.

Relationships

Explanation: Concepts are ideally freestanding and understandable in isolation. However, in a real application, they must interact. Relationships define how concepts compose and synchronize with one another. Sometimes one concept logically depends on another to exist in a specific product. Compositions range from loose (running in parallel) to synergistic (where one concept amplifies the other).

Example:

  • Synchronization: Composing a Todo concept with a Label concept. We establish a rule: when the Todo.delete(task) action is triggered, it automatically forces the Label.clear(task) action to execute, ensuring no orphaned labels remain.
  • Synergy: Composing the generic Trash concept with the Folder concept in an OS. Because the trash is represented as a folder, it inherits all folder behaviors natively (sorting, searching, viewing) without needing custom UI built just for the trash.