naresh's picture

Domain-Driven Design

Domain-Driven Design (DDD) is an approach for dealing with highly complex domains using a well thought-out domain model. This article explains DDD concepts using a real example. For a detailed description of the approach please refer to the Domain-Driven Design book by Eric Evans.

The example used in this article is Bullsfirst, a sample trading system built to demonstrate the use of best practices and patterns to solve real world problems. The diagram below shows the Bullsfirst vision. It consists of several system components built using a variety of technologies as a means of learning and evaluating different design approaches and platforms.

Bullsfirst Vision

At a very high level, users can enter orders to buy and sell securities through a front-end. The orders are managed in 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, play with the live demo of the system to get a good feel for it.


It's a great  article and liked the way you related it  the bullsfirst app. I was going over the internet and read about the Anti-Corruption pattern in DDD. Do you have something similar in the Bullsfirst app?   Thanks, Ramanjit    
naresh's picture

Great question! An anti-corruption layer is generally used to shield an application from another that does not have a clearly defined domain model or no domain model at all (e.g. some legacy applications). The anti-corruption layer usually takes the form of a service that translates the complexities of the legacy system and presents them in terms of a "friendly" domain model. Bullsfirst did not need any anti-corruption layer because both of its applications (the OMS and the Exchange) were built from scratch using DDD techniques and their models are largely compatible.

Naresh, First of all, I'll really appreciate your initiative to bring all like minded people under the same roof. Really liked your presentation on DDD, here are my thoughts/queries. There is a clear cut distinction between domain model, schema model(ER model) and class model but most of the time people use the terms like domain model and actual schema model interchangeably. I assume that your presentaion was more on strict domain model that may later be converted into schema model. Now the question arises between object driven development or data driven development ? What do you think should be the approach of an architect - to come up with normalized schema design from domain model and then do the reverse engineering of creating the domain/model layer vs. creation of object model from domain model and then create schema model out of it (very much like grails does). I think there is a big performance difference in adapting either of the apprach, I personally used both of these modelling in different engagement but still I do not have any conclusion. Really aprreciate your experienced comments on this.   --AS

naresh's picture

Ashish, you are correct - my presentation was definitely focused on domain models. I consider these models to be closer to the problem domain rather than the technology domain (which is what schema models/ER models, or even class diagrams as generally drawn by software developers are). Domain models, on the other hand, reflect the Ubiquitous Language spoken by domain experts and should be understandable by them even if they don't know technology.

To your second point, rich domain models are not just about data, but also about modeling the correct behavior and putting it in the right place (in entities and/or domain services). For me this translates quite easily to an object model and I let persistence frameworks worry about generating the schema (of course, most persistence frameworks provide decent control over what is generated). More importantly, this works well when I am iterating over my domain model - any changes to my objects are correctly reflected in the schema.

I don't have much experience in the reverse approach, i.e. starting from the schema, but I am guessing that it would be a bit cumbersome. What happens if I decide to change my schema after I have added bunch of methods to the generated objects? Unless the object generator is very smart, it will wipe out my customizations. In the object-to-schema approach this issue does not arise because I never touch the generated schema. Anyway, this is just a guess. Perhaps some Ruby experts can comment on how they do DDD starting from a database schema.

Nice article, very clear and loud. To me domain object model often closely maps to db model. Hence I feel domain object model should have access to atleast db persistence service and should have ability to do save and update itself and related entities. For read operations I deliberately like to take it away from domain object as it tends to get polluted with support for multiple parameters.