Hubbry Logo
Domain modelDomain modelMain
Open search
Domain model
Community hub
Domain model
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Domain model
Domain model
Domain model
View on Wikipedia
from Wikipedia
Sample domain model for a health insurance plan

In software engineering, a domain model is a conceptual model of the domain that incorporates both behavior and data.[1] In ontology engineering, a domain model is a formal representation of a knowledge domain with concepts, roles, datatypes, individuals, and rules, typically grounded in a description logic.

Overview

[edit]

In the field of computer science a conceptual model aims to express the meaning of terms and concepts used by domain experts to discuss the problem, and to find the correct relationships between different concepts. The conceptual model is explicitly chosen to be independent of design or implementation concerns, for example, concurrency or data storage. Conceptual modeling in computer science should not be confused with other modeling disciplines within the broader field of conceptual models such as data modelling, logical modelling and physical modelling.

The conceptual model attempts to clarify the meaning of various, usually ambiguous terms, and ensure that confusion caused by different interpretations of the terms and concepts cannot occur. Such differing interpretations could easily cause confusion amongst stakeholders, especially those responsible for designing and implementing a solution, where the conceptual model provides a key artifact of business understanding and clarity. Once the domain concepts have been modeled, the model becomes a stable basis for subsequent development of applications in the domain. The concepts of the conceptual model can be mapped into physical design or implementation constructs using either manual or automated code generation approaches. The realization of conceptual models of many domains can be combined to a coherent platform.

A conceptual model can be described using various notations, such as UML, ORM or OMT for object modelling, ITE, or IDEF1X for Entity Relationship Modelling. In UML notation, the conceptual model is often described with a class diagram in which classes represent concepts, associations represent relationships between concepts and role types of an association represent role types taken by instances of the modelled concepts in various situations. In ER notation, the conceptual model is described with an ER Diagram in which entities represent concepts, cardinality and optionality represent relationships between concepts. Regardless of the notation used, it is important not to compromise the richness and clarity of the business meaning depicted in the conceptual model by expressing it directly in a form influenced by design or implementation concerns.

This is often used for defining different processes in a particular company or institute.

A domain model is a system of abstractions that describes selected aspects of a sphere of knowledge, influence or activity (a domain[2]). The model can then be used to solve problems related to that domain. The domain model is a representation of meaningful real-world concepts pertinent to the domain that need to be modeled in software. The concepts include the data involved in the business and rules the business uses in relation to that data. A domain model leverages natural language of the domain.

A domain model generally uses the vocabulary of the domain, thus allowing a representation of the model to be communicated to non-technical stakeholders. It should not refer to any technical implementations such as databases or software components that are being designed.

Usage

[edit]

A domain model is generally implemented as an object model within a layer that uses a lower-level layer for persistence and "publishes" an API to a higher-level layer to gain access to the data and behavior of the model.

In the Unified Modeling Language (UML), a class diagram is used to represent the domain model.

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Domain model

View on Grokipedia
from Grokipedia
A domain model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. In software engineering, it represents a rigorously organized and selective abstraction of domain knowledge, distinct from mere diagrams or expert intuition, to capture essential concepts, relationships, and rules in a form suitable for implementation. This model serves as the conceptual backbone for object-oriented analysis and design, illustrating noteworthy entities and their interactions within a problem domain to guide software development. Domain models originated in the broader field of object-oriented modeling during the 1990s, evolving as a core artifact in methodologies like the Unified Process, where they inform requirements analysis and system architecture without prescribing implementation details. Their prominence grew with the introduction of Domain-Driven Design (DDD) in 2003, an approach that emphasizes building a deep, shared understanding of the domain through collaborative modeling between developers and domain experts. In DDD, the domain model is expressed through a ubiquitous language—a common vocabulary binding the model to team communication—and is refined iteratively to ensure logical consistency and relevance. Key elements include entities (objects with unique identities), value objects (immutable descriptors), aggregates (clusters of related objects treated as units), and services (operations not tied to a single entity), all bounded by contexts to manage complexity in large systems. The creation of a domain model typically involves visual representations like class diagrams or entity-relationship models, but its true value lies in its evolution from analysis to code, fostering software that aligns closely with business needs. By focusing on the core domain rather than peripheral or generic aspects, it enables refactoring toward deeper insights and supports strategic decisions, such as identifying subdomains or integrating with other systems. Widely adopted in enterprise applications, domain modeling promotes reusability, maintainability, and stakeholder alignment, though it requires ongoing collaboration to avoid superficial or inconsistent representations.

Fundamentals

Definition

A domain model is a system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain. It serves as a conceptual representation of the domain's key elements, capturing both data structures and behaviors in a simplified form that abstracts relevant real-world aspects while ignoring extraneous details. This model focuses on the essential concepts, relationships, and rules of the domain, providing a structured interpretation of reality tailored for software development. Unlike physical or technical models, which emphasize implementation details such as database schemas or hardware configurations, a domain model remains independent of specific technologies or deployment choices. It prioritizes business concepts and their interactions, ensuring the software design reflects the domain's logic without being constrained by incidental technical concerns. Central to this approach is the use of a ubiquitous language, a shared between domain experts and developers that forms the backbone of communication, , and , fostering alignment and reducing misunderstandings. In the context of (DDD), the domain model plays a foundational role by encapsulating complex in a way that mirrors the problem space. For example, in a simple e-commerce domain, the model might outline core abstractions such as products (e.g., parts with attributes like price), orders (e.g., purchase orders with line items and limits), and customers (with associated identifiers), illustrating relationships like order totals not exceeding approval limits.

Core Principles

The core principles of domain modeling in domain-driven design guide the development of models that effectively capture complex business domains while promoting clarity, consistency, and maintainability. These principles emphasize abstraction to distill essential domain concepts and collaboration to align technical implementations with business realities. Central to this approach is the isolation of concerns and the integration of behavioral logic, ensuring that models remain focused and adaptable. A key is the use of bounded contexts, which define explicit boundaries around subdomains to isolate them and prevent the formation of monolithic models that could lead to and inconsistency. Within a bounded context, a specific domain model is defined and applicable, allowing teams to manage large-scale structures by scoping models to particular aspects of the system, such as separate codebases or database schemas for distinct subdomains. This isolation protects logical consistency by limiting interactions between contexts and clarifying the applicability of each model, thereby avoiding ambiguity in how domain elements are interpreted across the broader system. Another foundational principle is the ubiquitous language, a shared developed collaboratively between domain experts and developers to bridge business and technical perspectives. This serves as the backbone of all team communications, code naming, and documentation, ensuring precision and reducing misunderstandings by committing the team to its relentless use. By structuring discussions and artifacts around this common terminology—derived from the domain model itself—it unifies activities and reinforces a consistent understanding of the domain, making the model more supple and aligned with real-world business needs. Domain models further prioritize behavior over mere data structures, embedding business rules and invariants that enforce essential constraints and processes within the model. Invariants represent assertions that must always hold true, except during transient operations, capturing the dynamic rules that govern domain operations rather than static attributes alone. This focus ensures that the model actively expresses the intended behaviors, such as enforcements or consistency checks, thereby providing a robust foundation for software that truly reflects the domain's logic and requirements.

Historical Context

Origins in Modeling

The conceptual foundations of domain models trace back to early efforts in during the 1970s and 1980s, where abstractions of real-world entities and processes were formalized to bridge problem domains and technical implementations. One key precursor emerged from , with Peter Chen's 1976 entity-relationship (ER) model providing a structured way to represent entities, attributes, and relationships in a that captures semantic elements of the real world. This approach emphasized domain abstraction by focusing on the logical structure of data independent of physical storage, influencing later modeling techniques that prioritize business semantics over implementation details. In parallel, the rise of object-oriented analysis in the 1980s introduced modeling practices that viewed domains through interconnected objects, laying groundwork for more holistic representations. Grady Booch's pioneering work, including his 1982 paper on object-oriented design, advocated for modular, hierarchical structures to model complex systems, drawing from Ada implementations but emphasizing reusable abstractions of domain concepts. These methods shifted focus from procedural flows to object interactions, enabling analysts to encapsulate domain knowledge in classes and relationships, which became integral to subsequent domain-centric approaches. During the , domain modeling gained prominence in object-oriented methodologies, particularly with the development of the () in by , James Rumbaugh, and . provided standardized visual notations, such as class diagrams, for representing domain and relationships. Domain models became a core artifact in the (), an iterative framework introduced in the late , where they supported and informed architecture during inception and elaboration phases. This period solidified domain models as essential for capturing domain without dictating , setting the stage for advanced approaches like . Early adoption of domain modeling also appeared in through techniques developed in the late 1970s. Tom DeMarco's 1979 book, Structured Analysis and System Specification, outlined tools like data flow diagrams and entity-relationship charts to decompose business processes into functional and informational components, facilitating clear specification of domain requirements. This framework promoted rigorous abstraction of organizational domains, ensuring models reflected real-world workflows without premature commitment to code. These foundational practices in evolved over time, contributing to specialized methodologies like in the 2000s.

Evolution in Domain-Driven Design

The seminal work formalizing the role of domain models in (DDD) was Eric Evans' 2003 book Domain-Driven Design: Tackling Complexity in the Heart of Software, which positioned domain models as essential for managing complexity in large-scale software systems by emphasizing ubiquitous language and bounded contexts to align code with business domains. Evans' approach built on earlier modeling but uniquely integrated them into a cohesive for collaborative between domain experts and developers. Following Evans' foundational text, subsequent developments in the and early refined DDD's practical application, with Vaughn Vernon's book Implementing Domain-Driven Design providing detailed guidance on tactical patterns such as entities, value objects, and aggregates to operationalize domain models in . Vernon's work extended Evans' strategic focus by offering concrete implementation strategies, including event sourcing and CQRS, to make domain models more actionable in real-world projects. In the 2010s, DDD evolved further through its integration with agile methodologies and architectures, enabling scalable systems where domain models define service boundaries to support iterative development and decentralized teams. This adaptation addressed challenges in distributed systems by leveraging bounded contexts for , as exemplified in Chris Richardson's 2018 book Microservices Patterns, which applies DDD principles to decompose monoliths into domain-aligned services while aligning with agile's emphasis on . Into the , DDD has continued to evolve, incorporating cloud-native technologies and event-driven architectures for resilient systems, as well as AI tools for collaborative modeling and , as of 2025.

Key Components

Entities and Value Objects

In domain modeling, entities represent objects that are distinguished by their unique identity rather than their attribute values, allowing them to maintain continuity and track changes over their lifecycle. An entity's identity, often implemented as a such as an ID, ensures that it can be referenced and updated while preserving the object's conceptual continuity, even as its attributes evolve. Entities encapsulate through methods that manage state transitions, ensuring that domain invariants—such as rules that must always hold true—are upheld during these changes. For instance, a entity might have methods to update personal details or transaction history, but its identity remains constant throughout its existence. Value objects, in contrast, are immutable constructs defined solely by the attributes they describe, lacking a distinct identity and thus interchangeable if their match. Equality for value objects is determined by comparing all their attributes, promoting simplicity and avoiding the need for unique identifiers. This immutability prevents issues and side effects, as value objects cannot be modified after creation; instead, new instances are produced for any required changes. A typical example is an value object, comprising attributes like street, city, and , where two addresses with identical values are considered equivalent regardless of how they were instantiated. To illustrate the distinction in a practical domain, consider a banking system where an Account serves as an , trackable by a unique account ID to manage its balance and transaction history over time, while functions as a value object, characterized by an amount and (e.g., 100 USD), with equality based on these values alone. Entities like the Account handle identity-driven operations, such as withdrawals that alter state while enforcing rules like sufficient funds, whereas value objects like provide descriptive, lightweight components that can be freely composed without lifecycle concerns. This separation enhances model clarity by assigning identity only where persistence and continuity are essential.

Aggregates and Boundaries

In Domain-Driven Design, an aggregate is a cluster of associated entities and value objects that are treated as a single unit for the purposes of data changes, ensuring the consistency of the group's invariants within a defined boundary. The aggregate root, which is an entity, serves as the sole entry point for external interactions, enforcing business rules that must always hold true across the cluster, such as ensuring an order's total value does not exceed predefined limits when line items are added or modified. This design prevents direct access to internal elements, isolating the aggregate's consistency from broader system concerns and promoting transactional integrity. Aggregate boundaries delineate the scope of consistency enforcement, limiting modifications to one aggregate instance per transaction to avoid concurrency issues and maintain performance. For instance, in a sales domain, an Order aggregate might encompass the order entity as the root along with its line items and shipping details, but it would not include customer information, which belongs to a separate aggregate; references between aggregates are handled via identifiers only, such as an Order referencing a . These boundaries are drawn based on true business invariants rather than artificial constraints, with empirical data from projects like Qi4j indicating that effective aggregates often contain just one or two entities to enhance and reduce locking overhead. The repository pattern supports aggregate persistence by providing methods to load and save entire aggregates atomically, typically accessing only the root to retrieve the full cluster. Introduced in Domain-Driven Design, repositories abstract the storage mechanism, allowing developers to treat aggregates as in-memory objects while ensuring that all changes are committed consistently, thus aligning persistence with domain logic. This approach facilitates refactoring and scalability, as seen in redesigns where monolithic aggregates are split into smaller, interconnected ones without altering external interfaces.

Construction and Techniques

Modeling Process

The modeling process in domain-driven design (DDD) is an iterative, collaborative workflow that builds a domain model by progressively uncovering, articulating, and refining the business domain's core concepts to ensure alignment with organizational needs. This process, often referred to as the "" model exploration by Eric Evans, emphasizes continuous feedback loops between domain experts and developers to evolve the model over time. It integrates core DDD principles, such as the , which serves as a shared vocabulary guiding all stages to maintain conceptual consistency. The process begins with domain exploration, where teams engage in techniques like or structured interviews to identify core subdomains and key business . , a format developed by Brandolini, involves collaboratively plotting domain on a timeline using colored to visualize processes, hotspots, and points without preconceived models. Through these methods, participants distinguish between core subdomains—those central to —supporting subdomains for essential operations, and generic subdomains that can leverage external solutions, as defined by Evans. This initial phase fosters shared understanding and prioritizes areas for deeper modeling. Next comes iterative modeling, where the ubiquitous language emerges and is used to define the domain's building blocks: entities, value objects, and aggregates. Entities capture objects with unique identities that change over time, such as a customer account, while value objects describe attributes without identity, like an address that is immutable and replaceable. Aggregates group related entities and value objects into transactional consistency boundaries, enforced by an aggregate root to protect invariants, such as ensuring order totals remain accurate during modifications. Modeling proceeds in cycles, refining these elements through discussions and prototypes, with the ubiquitous language ensuring terms like "shipment" or "invoice" are precisely defined and consistently applied across the team. Finally, refinement involves testing and evolving the model through with domain experts, verifying that invariants—critical rules like "no on accounts"—hold under various scenarios. Teams conduct workshops to challenge assumptions, simulate use cases, and adjust definitions based on feedback. To handle in large domains, bounded contexts are introduced as explicit boundaries around subdomains, allowing independent evolution of models while defining integration points via context maps. This stage ensures the domain model remains practical and adaptable, with iterations continuing as understanding deepens.

Representation Methods

Domain models are commonly represented using UML class diagrams to depict the static of the domain, including classes that correspond to entities and value objects, their attributes, associations between them, and multiplicities to indicate constraints. This notation facilitates a clear visualization of relationships, such as one-to-many associations between domain concepts, without delving into . In Domain-Driven Design (DDD), additional notations extend beyond standard UML to address strategic aspects. Context maps, as introduced by Eric Evans, illustrate relationships between multiple bounded contexts, using elements like upstream-downstream partnerships or shared kernels to denote integration points and dependencies. Hexagonal architecture sketches, originally proposed by , complement these by portraying the domain core at the center, surrounded by ports for external interactions and adapters for infrastructure concerns, emphasizing isolation of business logic. Tools like and support collaborative creation of these representations through text-based or drag-and-drop interfaces. enables diagram generation from simple textual descriptions, such as defining classes for an aggregate like an Order with associated OrderLine items, rendering associations and boundaries automatically. provides pre-built templates for domain object modeling, allowing teams to sketch UML class diagrams or context maps with real-time collaboration, as seen in examples visualizing aggregate boundaries around entities.

Applications and Implications

Role in Software Development

In domain-driven design, the domain model is mapped to the domain layer of , where it encapsulates core logic, entities, and rules, isolating them from and concerns to ensure the software reflects the domain's conceptual . This mapping aligns with clean principles, positioning the domain layer at the center to depend only on itself, while outer layers like application services and adapters interact with it through defined interfaces, thereby maintaining focus on rules without technical . Domain models significantly influence by delineating service boundaries along bounded contexts, where each microservice implements a cohesive subset of the domain model to handle specific capabilities independently, reducing and enabling scalable deployments. In this approach, the domain model within a bounded context guides the microservice's internal structure, ensuring that ubiquitous language and model elements are consistent across code, tests, and communications, which supports evolutionary design in distributed systems. A practical illustration of this role appears in e-commerce systems, such as the eShopOnContainers reference application, where the domain model—comprising entities like orders, products, and catalogs—directly shapes endpoints for operations like order placement and inventory management, ensuring RESTful interfaces expose domain behaviors without leaking implementation details. Furthermore, in this , the domain model informs the by translating aggregates and value objects into persistent structures, such as using collections for bounded contexts like ordering to preserve transactional consistency and denormalization aligned with invariants. This integration, built upon prior modeling techniques, facilitates a maintainable that evolves with requirements.

Benefits and Challenges

Domain models in (DDD) enhance maintainability by providing clear abstractions that encapsulate , making systems easier to extend and adapt over time without introducing unintended side effects. This supple design approach ensures that changes in one part of the model do not propagate unpredictably, fostering long-term evolvability in complex software systems. A key advantage is improved team communication through the adoption of a ubiquitous , a shared derived from the domain that bridges the gap between technical developers and stakeholders. This common model reduces misunderstandings and ensures that discussions, documentation, and code reflect the same conceptual understanding, leading to more aligned decision-making throughout the project lifecycle. Furthermore, domain models contribute to reduced in evolving systems by prioritizing the core domain early in development, allowing teams to focus resources on high-value business capabilities rather than peripheral features. This strategic emphasis minimizes the accumulation of suboptimal code and architectural mismatches that often arise in rapidly changing environments. Despite these advantages, domain modeling faces challenges such as over-modeling, where excessive in simpler scenarios leads to unnecessary and increased development overhead. This can result in bloated models that hinder rather than help, particularly when DDD principles are applied indiscriminately without assessing domain . Initial discovery of domain elements proves difficult in large domains, as identifying bounded contexts, entities, and relationships requires deep exploration amid vast and interconnected business processes, often overwhelming teams without structured guidance. Additionally, resistance from non-technical stakeholders arises due to the unfamiliarity with modeling concepts and the perceived from immediate concerns, potentially stalling and adoption. To mitigate these issues, practitioners recommend starting with core subdomains—those central to —and iteratively refining the model as understanding deepens, avoiding comprehensive upfront design that risks over-modeling. This phased approach allows for incremental validation and adjustment based on feedback. Workshops, such as sessions, facilitate alignment by involving stakeholders in collaborative modeling activities that build the ubiquitous language organically and address resistance through hands-on participation. These techniques promote shared ownership and iterative discovery, ensuring the model remains practical and stakeholder-endorsed.

References

  1. https://www.oreilly.com/library/view/domain-driven-design-tackling/0321125215/
  2. https://www.oreilly.com/library/view/applying-uml-and/0131489062/ch09.html
  3. https://www.domainlanguage.com/wp-content/uploads/2016/05/DDD_Reference_2015-03.pdf
  4. https://fabiofumarola.github.io/nosql/readingMaterial/Evans03.pdf
  5. https://martinfowler.com/bliki/DomainDrivenDesign.html
  6. https://www.thoughtworks.com/en-us/insights/blog/agile-project-management/domain-modeling-what-you-need-to-know-before-coding
  7. https://dl.acm.org/doi/10.1145/320434.320440
  8. https://www.ibm.com/docs/en/rup/7.0.0?topic=overview-rational-unified-process
  9. https://dl.acm.org/doi/book/10.5555/1102012
  10. https://www.oreilly.com/library/view/implementing-domain-driven-design/9780133039900/
  11. https://www.informit.com/store/implementing-domain-driven-design-9780133039894
  12. https://martinfowler.com/articles/microservices.html
  13. https://microservices.io/articles/ddd-eventstorming.html
  14. https://www.temjournal.com/content/141/TEMJournalFebruary2025_44_54.pdf
  15. https://martinfowler.com/bliki/EvansClassification.html
  16. https://medium.com/@arun.badhai/entity-value-object-aggregate-and-aggregate-root-in-ddd-9fb9342c1df0
  17. https://www.domainlanguage.com/ddd/reference/
  18. https://www.dddcommunity.org/wp-content/uploads/files/pdf_articles/Vernon_2011_1.pdf
  19. https://www.domainlanguage.com/ddd/whirlpool/
  20. https://www.eventstorming.com/
  21. https://martinfowler.com/bliki/DDD_Aggregate.html
  22. https://github.com/ddd-crew/ddd-starter-modelling-process
  23. https://alistair.cockburn.us/hexagonal-architecture
  24. https://lucid.co/templates/domain-object-modeling
  25. https://developer.android.com/topic/architecture/domain-layer
  26. https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice
  27. https://martinfowler.com/bliki/BoundedContext.html
  28. https://learn.microsoft.com/en-us/azure/architecture/microservices/model/microservice-boundaries
  29. https://www.dddcommunity.org/wp-content/uploads/files/discussion/ReadingDDDForManagers.pdf
  30. https://www.infoq.com/articles/ddd-in-practice/
  31. https://www.kranio.io/en/blog/de-bueno-a-excelente-en-ddd-errores-comunes-y-anti-patrones-en-domain-driven-design---10-10
  32. https://concisesoftware.com/blog/domain-driven-design-discovering-domains/
  33. https://www.infoq.com/articles/architecture-modernization-domain-driven-discovery/
  34. https://www.concettolabs.com/blog/what-is-the-importance-of-domain-driven-design-ddd-in-net-development/
  35. https://delivery-playbooks.rise8.us/content/practices/domain-driven-design/
  36. https://www.rst.software/blog/event-storming-101-flexible-workshop-approach-to-domain-driven-design
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.