Domain Driven Development- An Introduction.

[sgmb id=3]

So, I have been in one of the tech talks and there I got to know about this methodology named domain driven development. It was first described by Eric Evans and from then the domain driven development philosophy came into picture.

So what really is this philosophy

The idea is to focus on the heart of the application, focusing on the complexity that is intrinsic to the business domain itself. We also distinguish the core domain ( unique to the business ) from the supporting sub-domains ( typically generic in nature, such as money or time ), and place appropriately more of our design efforts on the core. [ Taken from this article ]

The main focus of this philosophy

Ubiquitous language

Keeping a consistent language across your product will help you and other to understand and well and build around it. Lets take an example of Address, you may use street, locality, adress_line_2 anything for workaround. But should you really do this and confuse your developer, product guy, even consumers sometimes. So keep the language consistent and thus it will help it better understanding and every person will be on the same page.


With model here we don’t mean the ER diagrams or the database model. Here we refer as the  set of concepts that we chose to implement in our product, it can be represented in any software or code itself. Models are like saving a cost. There are many ways to save the cost. We can save it in simple int or double. But this may cost us problem in future so thinking about the model is very important. Lets say you used double for saving the cost and now your product is launched in countries with different currency thus leading to code change which is done at every place currency is present leading to bad code for future. A better implementation could be

A = cost(value, currency)

And small functions to add subtract etc.

Now you may say it is over engineering for a startup. Yes you are right it is an over engineering and that is why the world is all about trade-offs.

Context or Bounded Context

Every domain model stays in it areas totally in separation from other contexts.  So now the constraint is that we cannot build relationship among the model we build as they remain in their context. Thus is it a bad model and how can we interact between models and it is very very important to make business logics.

Domain Driven development defines new set of rules between the bounded contexts. Thus the relationship is solved by these linking of BCs together.

Published Language

The interacting BCs agree on a common a language  by which they can interact with each other. This language is known outside the domain for other domains to interact. Subdomains agree on language first to do so.

Open Host Service

Gives a protocol to use to interact. It is similar to providing apis and RESTFUL webservice.

Shared Kernel

Two BCs work on common library or kernal of code. The part of code that is fixed will not change thus can be used by other to interact. Such code comes in this section.


BC uses the services of another and is a stakeholder (customer) of that other BC. As such it can influence the services provided by that BC and this may also induce changes.


BC uses the service of another BC but cannot make changes in that because it is not stake holder. Its like Uber providing its apis which you can only use and cannot make them to change.

Anti-corruption layer

One BC uses the services of another and is not a stakeholder, but aims to minimize impact from changes in the BC, make some tweaks in the code or write a wrapper around it to.


This is a simple Introduction of Domain Driven Development. If you want to learn more dig deeper into the internet space. Many many things are not covered here try exploring them if you like this abstract.

Gaurav Yadav

Gaurav is cloud infrastructure engineer and a full stack web developer and blogger. Sportsperson by heart and loves football. Scale is something he loves to work for and always keen to learn new tech. Experienced with CI/CD, distributed cloud infrastructure, build systems and lot of SRE Stuff.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.