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 .

Bounded Context

The sheer volume of concepts on a large project can be daunting. For example, a typical brokerage firm will have a large number of interrelated functions such as customer acquisition, account management, order management, order execution and so on. Each of these functions will have some distinct and some overlapping concepts. One could theoretically conceive of a domain model for the entire enterprise, however such a large domain model is neither feasible nor cost effective. We must divide large domains into smaller manageable models, each of which is bounded within a context.

There is no magic formula to divide a large domain into smaller ones. The general rule of thumb is to group together elements that are related and form a natural function. The model should be small enough that it can be managed by one team without being distracted or confused by outside issues.

In this vein, we have broken Bullsfirst into two bounded contexts, each with its own model:

  1. Bullsfirst Order Management System: Responsible for order creation, maintenance and reporting
  2. Bullsfirst Exchange: Responsible for order matching and execution

While the two contexts have overlapping concepts (such as orders and executions), their focus is different enough that we should not tangle them together. A Context Map, such as the following, provides a higher level view to understand how the two models fit into the overall picture. As you can see, the Exchange treats an Order as a standalone entity – it is only concerned about matching orders and executing them. On the other hand, the OMS focuses on order management – it associates an order with BrokerageAccounts and Trades as the order progresses through its lifecycle.

Bullsfirst Context Map

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.

  • Leave a Reply

    View Comments (9) ...
    Navigation