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

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

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

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…

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

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.


Passionate engineer and Enterprise Architecture Practitioner who loves to learn & grow.