top of page
Writer's pictureMrudul Palvankar

Scale your business with Domain Driven Design




There are many Domain Driven Design (DDD) articles from a technical perspective with all technical terms and patterns. Well, this post is from a non-technical perspective to help business executives understand and relate to their business use cases. This post explains the Domain Driven Design technique, the benefits it brings to the organisation, and the business value this technique provides.


Solutions always overrun

Building software that meets the needs and expectations of businesses and users in a dynamic and ever-changing technological world can be challenging. Designing and building a solution is a non-trivial problem. They require constant changes to be effective to keep up with market changes. This generally leads to delays, over budgets and may create larger problems such as non-flexible solutions.


Why does this keep happening?


Let’s understand complex vs complicated

Building a profitable business is a complex problem, and complex is different to complicated.

 

  • Complicated problems can be hard to solve, but they are addressable with rules. Once you know how to apply them (the process), you have solved the complicated problem

  • Complex problems involve too many unknowns and too many interrelated components with no right answers, only best attempts. 

For example, "taxes" or “loan approval” are complicated. There are many rules and processes, but once you know how to apply them (the process), you have solved the complicated problem. Just follow the process and you will have the complicated problem controlled.

 

However, building a business solution is not the same, there are many unknowns in a business. Not only do companies have to worry about keeping up with change, but they also have to remain viable and relevant. For example a competitor with an innovative business model — an Uber or an Airbnb is a complex problem. 


Complex problems cannot be controlled with any process, rather, they need to be managed. Business development is a complex problem and we can not control it as a process or solve it with linear thinking. 

 

DDD acknowledges this fact and instead of following the business development as a process, it presents techniques to manage and remove ambiguity in complex systems. The technique is to iterate on the problem you are trying to solve until there is fair clarity.


Some research numbers on DDD

As per Standish Group’s analysis, 70% of projects were doing rework due to a lack of domain knowledge during the requirements and design phases. It also confirms that DDD fosters understanding between businesses and developers.


According to Forrester, development teams practising an iterative DDD model work 60% faster than if they spent months on upfront analysis.


Research conducted by the University of Cambridge found that modelling domain knowledge within a DDD framework leads to a 29% increase in team productivity. Clearly, this approach unlocks internal domain knowledge.


So what is Domain Driven Design (DDD)

Domain Driven Design is a collection of patterns and good practices that support software development. It focuses on the complete understanding of the domain for which the software is developed.


You may have a question: Does that mean, without DDD, the developers will not understand what they do?

 

The answer is No. However, some businesses are complex, and it's not easy to understand the business nor it is easy to say that "I fully understand this business".


Let us understand the DDD techniques


Focus on the problem

All solutions flow from problems. Hence understanding the problem is crucial. In DDD, this problem and its resulting knowledge or activities is termed as Domain and it is the driver of everything else. In other words, this is what your company does to make money.

 

For example your business is Marketplace that enables film producers to book any film related services such as shoot locations, crew, and talent (actor, model, singer etc.), your "core" domain (the one that drives your business) is selling for the sellers and buying for the buyers, everything else is secondary.

 

By enabling efficient and faster ways for selling and buying, you will grow your business. However, if you focus on maintaining the sellable products (locations, crew, and talent), then you are probably not going to grow your business.

 

DDD brings clarity on the core problem, and through clarity, we are able to focus on the core problem or the domain. It is extremely important that the development team understand your business, know how it makes money, and which processes are the most important for the organisation and which are not. This ensures that what is designed and crafted by architects and developers is what you and your users want.


Collaborate with the experts

If you want to understand a problem, you need to talk to the domain experts. A domain expert understands the problem better than anyone else, and they act as a  guide on what is important and what isn't.


In most organisations, the domain experts are not the ones building a solution. DDD helps to bridge the knowledge gap between what the domain experts know and what those building the solution are trying to understand. Hence majority of the DDD techniques do not talk about technology, instead they focus on people and ways to understand business complexity without any ambiguity. 


The DDD community offers a couple of techniques that ease the communication between business and the development team (IT team). These techniques are Event Storming, User Story Mappings, and Domain Storytelling, among others. The main purpose of these techniques is to bring together the domain experts (anyone who offers knowledge about the domain, like product owners, users, specific department employees, etc.) and software developers in one room to learn from each other.


Build a common language

One key way to gain clarity is to build a shared understanding of the problem, i.e. a domain model.


Have you ever had a situation where you talked with an IT representative and needed clarification about what you were talking about? You use business jargon, while a developer or architect uses a lot of technical terms like database, communication, events, etc. while you focus on the business processes, rules, user experience.

 

That’s why language is core to DDD. The solution is for everyone to work closely with domain experts to understand the language as the business defines it. This enables everyone to communicate, leading to less silos, better collaboration and simpler solutions.


Your solution reflects your understanding of the domain

Any solution you build is a direct reflection of how well you understand the problem or the domain.If you understand the domain thoroughly, the solution will always be good. Using your solution as a feedback, you can have further discussions and figure out if your solution is close to the problem or not, which leads to a better domain model, and a better solution. It's an iterative technique and it encourages us to focus on the approach to addressing the problem , rather than focussing on the end solution or the technology.


Team organisation and relationships

After identifying the core domain and the sub-domains or secondary domains, we can build teams around these domains. This results in dividing the company into departments, with a manager responsible for each department or subdomain. However, there are always dependencies between the subdomains. Thus, the teams must collaborate to a greater or lesser extent, as the case may be.

 

Domain Driven Design defines a set of patterns for team integrations. They determine how the models maintained by the team integrate. After having the team relationships defined, you may build a map of them. This allows them to discover how they work and communicate. It also shows how the change influences them, what are the bottlenecks or suboptimal team relations.


Below diagram shows a context map of team relationships of a Marketplace, where Selling & Buying is the core domain and others are secondary domains.


Diagram


To conclude

DDD puts the business and its domain at the core and it ensures an alignment between business and development teams by introducing common language and close cooperation. It helps implement more flexible solutions, which can be quickly adapted to changes in the business to increase competitiveness. It helps to divide the big complex business into smaller parts and understand what to focus on and what's not really important for your company.


All these benefits translate to the ones which boost your business:

  • Cost savings, as you know what subdomains are important and what is less. Also, you may notice the bottlenecks in team relations.

  • Increase in profitability, as you may optimise your staffing. Also, you know what areas really earn money and which are just supportive.

  • Faster time to market, as the design is ready for changes

  • User happiness, as the system does what it's intended to do and what customers expect


Why choose CNATIVES

For CNATIVES, the DDD approach is an integral part of our ideology of building long-term technical partnerships with customers. 


Here is why you should choose us.

We build well-crafted software

Our approach focuses on understanding your business / domain because we believe that “If we understand the domain, we can serve the domain better.


A working software does not have to be well-crafted. However only good professionals can build well-crafted software, and only well-crafted software lets you build faster than ever.


We offer affordable services

We give you a guaranteed price upfront and set a timeline. Our services are affordable because we have a set of pre-built libraries that helps build applications fast and with low cost.


We offer experience

Our experts have been building applications with 25 years of experience.

4 views0 comments

Commenti


bottom of page