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 :)


Thursday, October 20, 2016

Domain Driven Design Advantages and Disadvantages

In today's blog post, I will be discussing what domain driven design is along with it's advantages and disadvantages.

Domain Driven Design

The term "Domain Driven Design" was coined by Eric Evans in 2003 in his book titled "Domain Driven Design".


Domain Driven Design


The Domain Driven Design (DDD) is an approach to software design which makes us focus on the heart of the application i.e. complexity of the business domain rather than technical details. DDD contains a set of patterns for building enterprise applications from the domain model out.

Advantages of DDD

Here are the advantages of using Domain Driven Design:

i) Patterns

DDD gives us the principles and patterns to solve difficult problems in software as well as sometimes in business. These patterns have been successfully used to solve complex problems.

ii) History of Success

It has a history of success with complex projects. It aligns very well with the experience of developers and successful software applications already built.

iii) Clear Code

It helps us write clear and testable code that represents the domain. The code is more focused and concise

iv) Better Understanding

It helps us understand client needs better.

What It Involves

To look at the Domain Driven Design from a high level, here are a few critical pieces which are important for us to successfully follow DDD methodologies:

i) Interaction with Domain Experts 

There is a lot of back and forth interaction with Domain Experts. The communication between the developers and domain experts is critical to the success of this methodology and our software. We as developers need to understand their terminologies, how they want to use the system and their pain points.

ii) Focus on part of Domain

Since the domain is complex, we need to divide it into sub-domains. By doing this, we are keeping the conversation focused to a specific sub-domain at a time. This leads to better understanding on both sides.

iii) Focus on part of Domain (again;)

During development too, the focus is on one sub-domain at a time. It helps the modeling and implementing of sub-domain efficiently and directly ties into separation of concerns principles.

Advantages of DDD to Code

If we follow Domain Driven Design, the resultant code also has a few advantages:

i) Supple

By following DDD, the code is very flexible and will be easier to change and extend.

ii) Solving Customer Problem

The resultant code is generally much more close to customer's vision and perspective of the problem.

iii) Divide and Conquer

Since we are breaking the complex problem into smaller pieces, the resultant code is also easier to write and read. It is much better organized and it should have fewer issues and should be easier to test.

iv) Patterns to Leverage

Even if we don't use DDD by the word, it still helps us to see many great patterns to leverage.

Disadvantages of DDD

DDD comes with a lot of advantages. However, there are a few disadvantages as well:

i) Only if Domain is Complex

The real benefit of DDD shows up only if the domain is complex. If the domain is simple, then DDD might be an overkill.

ii) Time Consuming Upfront

The developers have to spend a lot of time with domain experts to understand the domain thoroughly. This can be time consuming on both ends. Also, deciding the sub domains and system boundaries can also take lot of time.

iii) High Learning Curve

DDD has a high learning curve initially. Getting used to this new way of thinking might be painful at first but I think we as developers do like to give ourselves pain :P

Conclusion

Domain Driven Design helps us focus on the client problem and guides us in the direction of solving it using divide and conquer technique. We will be delving deeper into DDD in subsequent blog posts.

References:
Domain Driven Design book By Eric Evans