user

Domain-Driven Design

Introduction

user

Naresh Bhatia

Naresh is a software architect in the Boston area. He started Archfirst after realizing that technologists spend too much time fighting technologies instead of solving real-world problems. Archfirst is a place where we can all learn best practices and techniques to make software development easier.


LATEST POSTS

JoinJS – An Alternative to Complex ORMs 10th August, 2015

MyBatis vs. Other ORMs 01st July, 2015

Domain-Driven Design

Posted on .

Domain Model

The domain model uses the Ubiquitous Language to provide a rich visual view of the domain. It primarily consists of entities, value objects and relationships. Let’s take a closer look.

Entity

We define a domain concept as an Entity when we care about it’s individuality, when it is important to distinguish it from all other objects in the system. An entity will always have a unique identifier. For example, in Bullsfirst, a BrokerageAccount is an entity with accountId as its unique identifier. An account with an id of ‘00718-5362’ is distinct from any other account or object in the system.

Brokerage Account

Aside from a unique identifier, an entity may have other attributes that define its characteristics, but those attributes do not have to be unique. For example, two brokerage accounts can have the same name, “My Brokerage Account”, and that’s just fine.

Value Object

An object that represents some descriptive aspect of the domain, but has no conceptual identity is called a Value Object. A good example of a value object is Money. While Money is defined in terms of an amount and a currency, it has no identity of its own – $100 is $100, it has no identity (at least in our domain).

Money

Entities vs. Value Objects

How can you tell if a domain concept is an entity or a value object? In addition to having a unique identity, an entity encapsulates state that can change continuously over time. Changes may be so extensive that the object might seem very different from what it once was. Yet, it is the same object with the same identity. On the other hand, a value object is just a value – it quantifies or describes a property of another object, usually an entity. If the property changes, the value object can be completely replaced by another with the new value. For example, if the current balance of a BrokerageAccount changes from $1000 to $2000, you can throw away the Money object that represented $1000 and replace it with a new one representing $2000.

Developers may have a tendency to model value objects as entities because they may need to store value objects as distinct rows in a database table. While this approach is required to implement a collection of value objects in the relational model, don’t let it influence your domain model. If you do, your domain model will not reflect true DDD thinking.

For a detailed discussion of these concepts, read Implementing Domain-Driven Design by Vaughn Vernon.

Relationships

Entities and value objects can be related to one another. It is valuable to show such relationships in our domain model. While it is easy to get bogged down with different kinds of relationships, I suggest that you start with the simple Association relationship – all it says is that two objects are related in some way. An association is shown by drawing a line between the related objects. For example, the diagram below shows that the BrokerageAccount entity is related to the Lot entity.

Relationship

The only other important aspect of a relationship is the multiplicity of each end. We want to somehow say that a brokerage account can have multiple lots. This is done by putting a ‘1’ on the BrokerageAccount end and a ‘*’ (representing ‘zero-to-many’) on the Lot end. Now the diagram reads as: “1 BrokerageAccount has zero-to-many Lots”.

Relationship with multiplicity

Note that I have also changed the layout to indicate that the BrokerageAccount is the “parent” in this relationship and the Lot is a “child”. A good layout can aid in the understanding of the domain, I recommend that you pay extra attention to it. A bad layout can cause unnecessary confusion. For example, putting the Lot above the BrokerageAccount would reduce the understandability of the diagram. When the two entities are peers, you may want to show them side by side.

The diagram above shows a one-to-many relationship. Other common relationships are one-to-one and many-to-many. For example, Country to Capital is a one-to-one relationship, whereas Student to Course is a many-to-many relationship. Also note that you can have relationships between entities and value objects and also between value objects and value objects. For example, in the diagram above, we could have pulled out the ‘pricePaidPerShare’ attribute from the Lot and shown it as a relationship between the Lot and the Money value object. These are equivalent representations, the latter gives more emphasis to the relationship.

Finally, here are some additional tips on creating good domain models:

  • Avoid introducing software concepts when creating a domain model. It is not an exercise in software design or database design! The focus should be on understanding the business domain and the functional requirements of the system under development. As a consequence, the domain model should be created and owned jointly by domain experts, software developers, UX designers and other members of the team.
  • A good domain model should translate directly into the core domain layer of the system without introducing technical concerns like persistence, input and output mechanisms. We will talk more about this in later sections.
  • The process of creating a domain model is very compatible with Agile practices. You don’t have to create the entire domain model before moving into implementation. It’s probably good to start with a general idea of the various subject areas in your domain and then deep dive into specific ones as needed for the feature under implementation.
  • Do not cram your entire domain into one diagram. A diagram with hundreds of objects and relationships is not understandable by normal human beings! Break it up into smaller subject areas. Remember the rule of Seven, Plus or Minus Two – limit the number of objects on your diagrams from 5 to 9!
  • Avoid crossing of relationships. If you can’t draw your diagram without crossing relationships, it is probably too complex. Break it into smaller pieces.

Pages: 1 2 3 4 5 6 7 8

profile

Naresh Bhatia

Naresh is a software architect in the Boston area. He started Archfirst after realizing that technologists spend too much time fighting technologies instead of solving real-world problems. Archfirst is a place where we can all learn best practices and techniques to make software development easier.

Comments
  • user

    AUTHOR Ilya

    Posted on 6:56 am March 25, 2015.
    Reply

    > BrokerageAccount is the aggregate root – it “owns” Orders or Transactions.

    But the collections of orders/transactions will grow unbounded eventually. What will you do in that case?

  • user

    AUTHOR Naresh Bhatia

    Posted on 7:30 am March 25, 2015.
    Reply

    Good point! To take care of this situation, I would break Orders and Transactions into seperate aggregate roots. This is not to take care of the read situation, but more of the write situation. A write must be transactional and must keep the aggregate consistent. With too many Orders and Transactions in the Account aggregate, we will run into version conflicts. This can be easily avoided by breaking Orders and Transactions into their own aggregate roots. In case of reads, we can always join as many entities we want and limit the results, so that’s not an issue – this follows from the Command Query Separation principle. Hope this clarifies.

  • user

    AUTHOR Matt

    Posted on 4:14 am March 26, 2015.
    Reply

    I am curious how this would fit in with Micro Services?

  • user

    AUTHOR Naresh Bhatia

    Posted on 10:58 pm March 29, 2015.
    Reply

    Good question, Matt. I would say that DDD is very compatible with micro services concepts. The micro services architecture style recommends breaking a large monolithic application into smaller services that communicate via lightweight mechanisms such as RESTful interfaces. This is analogous to the DDD concept of breaking a large domain into smaller sub-domains and drawing explicit boundaries around them, known as “bounded contexts”. Within each bounded context the domain terms have specific meaning. However they could have slightly different meanings across bounded concepts. For example, the term “Customer” may have a different set of attributes in the Order system vs. the Customer Support system. The analog of this in the micro services approach would be to break a large e-Commerce system into smaller micro services, an Order service to manage orders and a Customer Support service to manage support requests.

    For a detailed treatment of bounded contexts, you can refer to “Implementing Domain-Driven Design” by Vaughn Vernon (listed at the end of this post).

  • user

    AUTHOR Sridhar

    Posted on 12:17 pm April 7, 2015.
    Reply

    Great work and love reading through the documentation.
    To understand your domain model better do we have a class diagram that we can refer to? Of course I can download the source code and view it from eclipse but wonder if you have already prepared one.

  • user

    AUTHOR Naresh Bhatia

    Posted on 1:16 am April 8, 2015.
    Reply

    Sridhar, glad to know that you liked the work. I do have the full domain models for the OMS and the Exchange, but didn’t get the time to publish them yet. Will try to do it over the weekend.

  • user

    AUTHOR Nico Nel

    Posted on 2:38 am April 12, 2016.
    Reply

    For someone that have been “aware” of DDD for a very long time and “thought” he know a good bit about it, but only recently really started digging into the various aspect of design (software, ux, etc) this is the best article I’ve read on the topic (and I’ve read a LOT lately while waiting for my blue book)
    Please share this, it’s really easy to follow for all levels of expertise and every stakeholder should gain this kind of understanding of the topic.

  • user

    AUTHOR Vijay Gupta

    Posted on 1:07 pm September 19, 2016.
    Reply

    This is really a great article to understand the DDD. I was struggling to understand the DDD and read few online references but was not satisfied with my learning. This article provide complete picture of DDD in very concise, to the point manner.

    Many Thanks.

  • user

    AUTHOR mrs cheng

    Posted on 11:59 am March 29, 2017.
    Reply

    just want to point out a couple of typos:
    “For example, in the digram above” – diagram
    “It is not and exercise in software design or database design! ” – I think you meant “It is not an exercise in software design or database design!

    • user

      AUTHOR Naresh Bhatia

      Posted on 7:32 am May 31, 2017.
      Reply

      Thanks for pointing out, Mrs. Cheng. Very observant! These are now fixed.

  • Leave a Reply

    View Comments (12) ...
    Navigation