Domain Driven Design
Crafting a software from interpretation of business terminologies aka. domain in turn leads to better processes for coding/development. This reflects true software craftsmanship. Abstracting software helps to create domain models. These models can bridge the gap between complex business requirements and developer’s code.
The term DDD was coined by Eric Evans in his book, also an Interesting read for DDD:
With DDD the structure, design and language of code (including classes, methods, variables or any software module) should be in sync with business logic, requirements or domain. DDD can also be considered as a design pattern. This is cluster/combination of different domain objects that includes entity, value object etc. They all are treated as one single business unit/domain aka. subject area.
DDD Purpose
DDD gets everybody within a software development agile team, starting from business stakeholders to Product Owner to manager to domain experts to developers to quality analysts use a common language. This address end-users problem/use-case for design and development of software in more sensible way. It’s a ubiquitous language for everyone present in a software team.
Ubiquitous Language
It is used as a practice of building a common language between development team and end-users. This language should be based on the Domain Model. This is used in the software as software doesn’t cope well with ambiguities and any kind of gaps.
In Domain Driven Development there is another important concept of Bounded Context. It tackles with on dealing with large domain models and a large organisation. In order to deal with a large model. We can further sub-divide the model into different zones which is called as a Bounded Context.
In order to prevent different domains from polluting or corrupting or disturbing each other. We need to create a boundary between them. So we need to create a translation layer between different domains. This can be either uni or bi-directional. And can be implemented by using some of the well-known design patterns like adapter, facade, translator. Creating a layer might be a significant amount of effort some time. But it would protect your domain from outer influences.
DDD Advantages
- It makes communication simpler and flawless.
- Provides more flexibility as DDD is object-oriented and everything can be considered as object i.e. modular approach.
- Targets directly end-users that are connected to domain that is being address or needs to be solved.
Problem Space
Let’s consider a simple problem space of an e-commerce application. In this problem space first of all the business domain would be processing a particular order. And before a customer places an order the first thing they might do would be going through all the products. Then, if customer likes a particular product they might choose the ones they desire. Next step would be to confirm the order then they would choose a shipping type. Finally make required payment for chosen product. This way the app would then process the data that the client provides. So this user app consists of different layers like User Interface, Application Layer, Domain Layer, and finally the Infrastructure layer.
Microservice DDD
We can decompose bigger monolithic applications into smaller microservices. With some business logic, functions or modules defined based on domain is microservice based DDD design.
Domain-driven design (DDD) is divided into strategic patterns and tactical patterns. It’s also a good fit for functional languages. Strategic patterns are easy to map to any language. As they mostly cover a higher-level design of software (like bounded context, context map, translation layer etc.). This pattern is independent of any programming language or framework. Whereas tactical pattern relies solely on programming language. Some of FP patterns in DDD are Lenses for aggregates, monoids for value objects, monad for DI. Also, ensuring software development is side-effects free by using monads etc.
Conclusion
Opposite to DDD is Model Driven Design where we derive an implementation from UML flow diagrams. So DDD is an important tool to model complex business domains. Finding an appropriate construct to represent DDD pattern is the key. Also DDD is an effective architectural approach for both agile based teams and for microservice that can help to build systems that can withstand dynamic changes.
