In recent months, I found myself resorting repeatedly to Domain-Driven Design (DDD), and more specifically, its strategic component, in the work I do with different clients. Some of them are familiar or well-versed with the approach, while others are surprisingly struggling to leverage its full potential.

Today’s article is a high-level overview of what strategic DDD is, why it matters for CTOs, and how you can get started with it.

What is Domain Driven Design (DDD)?

According to Martin Fowler, DDD can be defined as follows:

Domain-Driven Design is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns.¹

I have a profound respect for Fowler, and although the definition he proposes is technically accurate, it could be both intimidating and slightly misleading for someone with limited exposure to the concept.

Intimidating, as it uses “domain model” as part of the definition, a concept many people unfamiliar with DDD might not fully understand.

Misleading, as it ends by suggesting that Eric Evans’ book might be just a catalog of patterns. In reality, it’s much more than that. DDD is not just a set of patterns, though such patterns are a key aspect that many practitioners have been applying with success.

I’d like to suggest a more approachable definition, one that focuses on conveying both the strategic and tactical dimensions of DDD

Domain-Driven Design is an approach to software development that centers on promoting a deep understanding of the business it serves, its strategy and its core differentiators, and then aligning software systems, architectural decisions and organisational setup to best support business needs. Introduced by Eric Evans in his 2003 book, DDD includes both high-level mental models and approaches to develop a deep business understanding, and low-level architectural patterns and approaches to guide the actual implementation.

While waiting for the gods to punish my display of hybris², let me spend some time elaborating on why I believe every CTO on earth should have DDD in their toolbelt, and specifically the strategic part.

What is the Strategic part of DDD?

In a nutshell, Strategic Design in DDD is the act of discovering the set of subdomains that collectively represent the problem space a business is trying to solve through software engineering. This might sound simple, but it’s one of the most challenging parts of DDD.

What this means in practice is that by following this approach, you’ll dissect the business you’re supporting, something that requires an insane amount of discussions with non-technical stakeholders.

Through those conversations, you’ll develop a deep understanding of the key aspects of the business that are a differentiating factor, a competitive advantage, and those that aren’t.

Though you’re technically never done with this approach, at some point, you’ll have built enough confidence around a domain map that will represent all your subdomains, and classify them into three categories:

• Core subdomains.
  These are the areas of your business where you do have or want to build a key competitive advantage. They are the things your company does better than anyone else, and those for which customers and users prefer your solution over others. Core domains are areas where you want to have full control of your future and high chances of success. You’ll typically want to build software for these subdomains in-house and have your best talent working on them.

• Generic subdomains.
  As the name suggests, generic subdomains aren’t particularly specific to your business, yet are required to operate it. They are generally commoditized services or capabilities, such as authentication and authorization, for which off-the-shelf solutions are usually available. Generic domains are necessary components for your business, but they won’t have any differentiating contribution to its success. They are great candidates for outsourcing, either via vendors or open source components.

• Supporting subdomains.
  These are subdomains that are specific to your business, yet they do not represent any significant competitive advantage. It’s sometimes challenging to fully grasp their nature as they share attributes with both generic and core domain. Supporting subdomains are the realm of “good enough”. You want them to be good enough not to become a burden for the customer or business, yet you want to be mindful of not investing too much time and energy in perfecting them. Depending on their nature, they are good candidates for either outsourcing or building in-house. When you go for the latter, you typically will allocate more junior engineers to work on them.

I find the following illustration helpful to visualize the relationship between the three classes of subdomains³.

It’s important to notice that strategic DDD focuses on the problem space, not your current architecture. It helps you bring clarity to the problems you have to focus on and which approach to take in different situations.

With that clarity, it will become easier to find effective ways to address those needs in the solution space, including buy vs build decisions, staffing, organizational setup, and prioritization.

Strategic DDD’s main benefits

While DDD won’t work against COVID, and it won’t replace 90% of software developers six months ago, it does have plenty of positive benefits.

Once you have done the work needed to draw a full domain map of your business, you will be able to use it to facilitate appropriate decisions in many areas of your job as CTO:

• Buy vs build decisions.
  Many companies do not have a structured approach to run buy vs build consideration, which often leads to one of the two extreme approaches: building everything in-house or outsourcing most of the work. Without a structured approach, those decisions are often taken ad hoc and are more driven by the personal preferences of the person in charge rather than specific business needs. DDD offers an effective model to review and drive your buy vs build decisions. Though it’s not a set of hard rules, the guideline should be to build in-house solutions for your core domains, buy generic domains, and try to buy or outsource as much as possible of your supporting domains.

• Organizational design.
  Once you have identified your business subdomains, you’ll want to design teams whose span of responsibility aligns with domain boundaries. While teams generally own more than a single subdomain, a specific subdomain should only be owned by a single team. In other words, there is a one-to-many relationship between subdomains and teams. I’ve often seen that combining DDD with Team Topologies makes for a great set of tools to reason about organizational structure. These two models help you balance cognitive load by distributing core domains across different teams, identifying platform capabilities, and helping define operating models.

• Staffing.
  Besides helping you reflect on how to organize people and teams, DDD can bring a lot of clarity to specific staffing needs. Following the rule that suggests you should have your most talented people work on core domains, you might discover that you don’t have enough senior profiles to properly cover all of them. Furthermore, a classification of a subdomain as core might lead you to realise that you are completely missing specific skills required to build it. A common case is when a team has been leveraging a third-party service to provide ML models for a subdomain that has now been classified as core. They might not have any senior data scientists in your team, a gap that DDD will help identify.

• Prioritization and focus.
  A powerful byproduct of DDD is better focus and prioritization. When living in an undifferentiated landscape, one where all sub-domains are considered equally important, it becomes challenging to prioritize the right work. In such cases, we often end up accepting compromises such as dedicating a fixed amount of resources to each subdomain, or worse, focusing most efforts on serving the individual needs of the most vocal stakeholders. DDD, and specifically the domain modelling part, provides a clear classification of the relative importance of each subdomain, equipping you with powerful arguments to decide when to reduce or even completely stop investments in certain areas.

That’s an impressive list of benefits, and I’m not even mentioning the improved maintainability and evolvability of the architecture you’ll build by following DDD’s patterns and low-level constructs!

How to get started

If you get your hands on the DDD book from Eric Evans⁴, you might feel overwhelmed by the amount of details and the apparent complexity of the topic. This reaction might put you off completely from even starting your journey in DDD. Please don’t!

This is an area where progress always trumps perfection. My recommendation is to approach this new paradigm (for you and your team) with curiosity and an exploratory mindset.

Read up on how to do domain mapping, and start asking a lot of questions to your business stakeholders around differentiation, competitive advantages, and ownership of business decisions. Get more people involved from your team and educate them on the key concepts as you go.

Once you have the first draft of the domain map, do not run straight for a massive reorganization. Instead, look for some quick wins that will cement both your and your team’s confidence in the approach.

Is there a clear generic domain you could migrate to a third party?

Is there a core domain you’re underinvesting in?

Do you have a team that spans way too many core domains?

Do you have strong people mostly working on generic or supporting subdomains?

Answers to these questions will be opportunities to make small but impactful adjustments and observe their impact. Progressively expand the scope and complexity of the questions you’re asking yourself, which will naturally drive more substantial changes.

If you keep doing that consistently, you will soon realise you have built a lot of confidence and made numerous positive changes to your team setup, architecture, or priorities.

Help keep this newsletter free

I love writing this newsletter, and I intend to keep it free forever.

If you want to support my work, you can engage with me in one of the following ways:

1. If you need help with your Startup, Company, or team, I can support through advisory or fractional services. Find out more on this page.

2. If you need personal support to overcome challenges and grow as an engineering leader, I can support you through Mentoring and Coaching. Find out more on this page.

3. If you are looking for continued support and the chance of joining a thriving community of like-minded people, I host a Community for engineering leaders. Find out more on this page.

If your needs fall into a different category, such as newsletter collaborations or sponsoring, please reply to this email or schedule a free call via this link.