Discover, Design, Develop — An Ideal Path for DDD
Eric Evans mentioned in the blue book Domain Driven Design (DDD) is meant to tackle the complexity in the heart of software but there is another common opinion in the industry that DDD increase the complexity of Software Delivery and Maintenance. Let’s talk about some of the primary reasons behind this opinion.
Strategic vs Tactical DDD
Before we go deeper let’s quickly understand the two sides of Domain Driven Design (DDD) — Strategic and Tactical DDD.
Strategic DDD is useful to divide large and complex business problem into multiple chunks with clear boundaries and specific responsibilities to build high level software design topology.
This is the phase where we discover the Business domain and build Domain Language, Domain Model etc.
Tactical DDD is a set of patterns and building blocks to refine the results of strategic patterns applied to a stage where it can be converted into working code.
This is the actual implementation phase where we deliver the software.
Domain Discovery without Developers
Organisations starts practicing DDD with a working group which includes Senior Architects and Engineering Leads. This kind of approach generally start well with high energy and spend good amount of time/effort on building the strategic design. Despite they do good on Strategic outcomes such as Domain Model, Bounded Context etc. but they fail to transform these outcomes into working code during the Tactical Phase. It’s primarily due to the lack of building the Ubiquitous Language and align the business mental model with developers who are responsible to translate this into code.
Ubiquitous Language is a cornerstone practice of Domain Driven Design. The idea behind this practice is very simple; if parties need to communicate efficiently then they need to speak same language. Most importantly there should not be any transition in the Domain Driven Design. If the senior folks drive the strategic part and then involve the developers bit later in the game is one of the primary reason for DDD to fail or increase the complexity of the delivery.
Tactical Oriented DDD
If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions. — Albert Einstein
In contrast to the above approach, there are teams who directly jumps into Tactical implementation without spending good time on discovery and business understanding. Strategic DDD is very crucial to create an impact in your organisation and without spending quality time in this part you won’t get the real fruit of DDD.
As Alberto Brandolini says, software development is a learning process, working code is a side effect. You can’t develop a code without involving yourself into this learning process and also building the right solution requires knowledge of the problem domain.
So generally these Tactical oriented teams will end up creating some implementation patterns and best practices into the team, that’s the impact they can create by using Domain Driven Design practices.
DDD But…
Domain Driven Design (DDD) is also referred along with microservices, Command Query Responsibility Segregation (CQRS) and Event Driven Architecture (EDA). For example, DDD concepts like Bounded Context used to define Microservices and Domain Events drive the flow of Event Driven Architecture. DDD has its own journey/path and it should not be influenced by any architectural style or frameworks.
Generally the choice of architectural style, frameworks or tools in the early stage of your life cycle will influence a lot on your implementation which in turn degrade the DDD practice.
Assess your culture
Domain Driven Design play a vital role in organization’s team and communication structure. It’s very common in any of the DDD talks or articles people refer the famous Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
This is an impact/outcome you are going to gain by following an effective Domain Driven Design practice, but it’s also equally important to assess your current company culture before you decide to start DDD practice. Let’s list down some of the important points to consider:
- Organisation layers for decision making
- Cross functional ability for collaboration
- Agility for delivery
- Adaption for Change (For example Micro services , DevOps Adaption)
If your organisation is either in the initial phase of transition or struggling to transform the above points then introducing DDD will further increase the complexity of your organisation.
Conclusion
Domain Driven Design (DDD) is like all-or-none law to get a real impact in your organisation. If you apply partially or without assessing your team’s ability/culture then instead of tackling the complexity its going to increase the complexity further. Of course you can make use of some patterns and practices in your software development but that’s not the real Domain Driven Design in Practice.
