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

Bullsfirst REST API 04th March, 2015

Bullsfirst 18th February, 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.

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?

  • Leave a Reply

    View Comments (3) ...
    Navigation