Domain Driven Design

Posted 10 December 2020

Domain-Driven Design is developed by Eric Evans. When thing likes microservices and agile didn’t exists, But Microservice bring back design to design ideal microservices, Domain-Driven Design brings to monolith world design monolith application as a microservice

What is Domain-Driven Design is?

Creative collaboration of software expert and domain expert. But It have some characteristic those are

1- Collaborative:

  • Business People and developers must work to daily throughout the project

2- Modeling:

  • Structure of the code should model or map to structure of the domain with in which problem is being solved
  • And idea is that a business user should be able to look at the overall the system and it make sense of structure
  • Changes are made to the domain which map to where code changes should occur
  • When changes happen in one place and easy to change other
  • changes happen in domain they don’t happen in code when that happen you need to able to get equivalent change and code as easily and quickly as possible

3- Domain-Driven Design is Incremental:

  • Come up with only enough architecture to solve the immediate problem
  • The code evolves to as you learn more about the problem and more architecture is added
  • Domain-Driven Design is follows and agile work flow


A domain-driven design architecture is designed to grow incrementally overtime


Domain-Driven design is organizing along certain well-defined boundaries first of those Bounded context

Bounded context

Natural division with in a business. for example in Book store something like Sales, accounts, shipping, warehouse etc. Way to keep context separate from each other is thinking in terms of “What are the responsible of the people working with in that “ In domain-driven design things that happen inside the context and stay inside the context. Is by allocating responsibility for communications between context to one small object


An Entity is an Individual with in a given context. much like an object/class in Object oriented programming world. Has one job and does one thing. That thing is done in specific context


An aggregate is a collection of entities you talk to through a single portal

Entity vs Aggregate

  • Portal in to aggregate looks like an entity it looks like one object that does one job
  • Portal entities use other entities in aggregate to get work done
  • Determining entity or aggregate may not be visible from the outside of the context
  • Contexts are often implemented as single aggregates or might not be a context might actually be implemented by multiple aggregates that are working together in order to get their work done


A Portal entity uses other entities with in an aggregate to accomplish tasks


Ubiquitous Language

Idea of the Ubiquitous Language is that within a given context that people who are working in that context use a language of their own. language of one context is different form the language in other contexts


The Language itself will be reflected with in the code


  • You will use this when talking about the problems that are solving
  • Reflected code itself
  • Used at domain level to describe work
  • Distinguish between actors (people) and role (tasks) Actors may accomplish tasks in different roles
  • “Ubiquitous language tries to identify roles for entities “Entities names after roles and not actor


Every entity in domain-driven design should be associated with only one context


Domain-Driven Design

  • Every entity should be associated with one context
  • Move away from relation database thinking. Giant component that could use everywhere it consider as bad thing
  • Bad to have single product-object in multiple context
  • Everything stays content specific.

And look at how the entities will communicate each other as they are getting work done there are two ways to do communication

1- Orchestrated / declarative system

Basic idea of an Orchestrated system is that  “One entity tells another entity what to do”

Declarative systems have a tight relationship between services. If you make a change to any downstream service, the upstream service will be impacted

2- Choreography / Reactive system

Reactive system solution for declarative system. A reactive system eliminates coupling relationship between downstream and upstream services

  • Can change downstream services without disrupting upstream services
  • Can add downstream services without disrupting upstream services
  • Also called a publish-subscribe model
  • Subscribers are unknown to the publishers


In domain-driven design, the majority of communication between entities should be a choreographed / reactive model

We have looked at some brief about Domain-Driven design some basic idea of how to build Domain-Driven Design. There event storming this is one of the techniques to build better Domain-Driven Design

Event storming

  • Can be used to analyze the domain/ business
  • Can be used to develop code that is modeling the business
  • Collaborative technique with business people
  • Design a system that models the structure and flow of activities with in the business

That you do in conjunction with business people in order to come up with a design for a system that models the structure and flow of activities the business itself

Some Books for Reference

Domain-Driven Design

Event Storming

Leave a Reply

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