Thursday, October 27, 2016

Domain vs Sub Domain vs Bounded Context in DDD

In today's blog post, I will be discussing some of the key terms in Domain Driven Design. There is a lot of confusion around these terms especially when one starts reading about Domain Driven Design.

Domain Driven Design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated patterns.  -Eric Evans

Domain

The terms domain refers to the problem space that we are trying to create the software for. This refers to the way actual business works. Understanding the domain is the most important constituent of Domain Driven Design. For example, if you are creating software for managing performance reviews of employees, then understanding how the performance reviews actually work, the whole end to end workflow, the needs and expectations of the customers, how it affects compensation, etc is what refers to the Domain. The domain will include employees, managers and performance reviews, etc.


Core Domain

By breaking the complex domain into multiple sub-domains, we follow the divide and conquer approach to understand the domain better. The core domain refers to the key differentiator for the customer's business - something they must do well and cannot outsource. It's important to separate the core domain from other sub-domains. This helps us to focus our effort on one thing at a time. So in our example of employee performance review, our core domain is the performance review itself. The core domain affects other domains like compensation or affected by badges awarded to employees in the system. Those sub-domains are outside the core domain.


Domain Sub Domain Core Domain Bounded Context

Sub-Domain

These refer to the sub-domains that our core domain must interact with. They can be other applications or features our application must support or interact with. So in our example above, compensation management and badges management are the sub-domains with which our performance review application interacts. The relationships between the sub domains reflect how various components of the organization interact with each other.

Domain Model

Domain Model refers to the abstraction of the domain. It is an interpretation of reality. Not every aspect of domain can be part of the model. It's the aspects chosen for implementation that constitute the model. The diagrams (e.g. UML Diagrams) and even English sentences can present various views of the model. For us developers, the code represent the model. The model doesn't necessarily mean the classes, it can be anyway the code is written. Domain model consists of analysis model, code model and the language. The domain model shows how the user interacts with the application for a sub-domain.

Bounded Context

Whenever we discuss model, it's within a context. For example, a person might be called a user in one context and employee in the other. Every domain model lives in one bounded context and a bounded context contains one domain model. The bounded context defines the application boundary that separates it from other parts of the system. Bounded context includes not only how the users interact with the part of the application (as represented by domain model) but also how other parts of the application interact with it. These might include files, messages, API calls, etc. So by defining these boundaries, we get to know that we might have to translate the concepts from one sub domain to another.
Ideally, there should be a bounded context for a sub-domain. However, in reality, that's not the case all the time. Bounded context is more technical in nature. For example, in our performance review management application, if we have sub domain of how admin interacts with the application. Within this sub domain, how admin searches for a performance review can in itself be a bounded context along with other bounded contexts.


Conclusion

So in today's post, we saw some of the key terms of Domain Driven Design. It's important to understand them well before going deep into DDD. We will be looking at some more of these terms in next week's post as well.
For future updates to my weekly blog, please subscribe to my blog via the "Subscribe To Weekly Post" feature at the right and follow me on Twitter. Until then Happy Coding :)


No comments:

Post a Comment