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-Driven Design, or DDD, is an approach for building high-quality software that meets core business objectives. It emphasizes collaboration among domain experts, developers, UX designers and other disciplines to create a domain model that reflects the needs of the business. This involves agreeing on common terminology (a.k.a. the Ubiquitous Language), identifying business entities, their behavior and relationships and organizing them in a way that lends itself to a clean and modular implementation.

This article explains DDD concepts using the example of a trading application called Bullsfirst. It is a sample application that demonstrates the use of best practices in software development. The diagram below shows the architecture of Bullsfirst.

Bullsfirst Platform

At a very high level, users can enter orders to buy and sell securities through the front-end. The orders are managed by an Order Management System (OMS), which is typically owned by a brokerage firm. The OMS places the orders in an Exchange where a matching engine matches them and executes trades. Before continuing, you may want to play with the live demo to get a feel for the application.

This article has been structured to introduce the fundamental DDD concepts upfront. If you are a domain expert, developer, UX designer, tester or anyone generally interested in learning about DDD, go through sections 2 (Ubiquitous Language) and 3 (Domain Model). For a deeper understanding, especially for developers, go through all the remaining sections.

Navigation
  1. Introduction
  2. Ubiquitous Language
  3. Domain Model
  4. Bounded Context
  5. Command-Query Separation
  6. Layered Architecture
  7. The Domain Layer
  8. Conclusion

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.

  • Leave a Reply

    View Comments (6) ...
    Navigation