Your IDP needs DDD

It has been more than two decades since Eric Evans published his book on domain-driven design (DDD). The idea was to create software designed after the business domain, using the same language and mental models people used outside of the software team.

We don’t talk about domain-driven design much these days. But as George Santayana said: “Those who cannot remember the past are condemned to repeat it.”

As Platform Engineering grows into a movement at scale, we need to revisit the past and apply some lessons from domain-driven design to our internal developer platforms (IDPs). Otherwise, we continually step on rakes to learn why they shouldn’t be left on the lawn.

There’s a host of interesting interconnected ideas in domain-driven design, but one that resonates with Platform Engineering is the concept of a core domain.

What core domains are

When you build software, there are several areas where your innovation, opinions, and solutions create unique value for your organization. You also need many things that don’t add much value, but your software isn’t viable without them.

Let’s use a pizza restaurant as an example. If you sell pizza, you want to make it easy for customers to choose what they want to eat and have it delivered. To complete the process, you need to look up their address and take a payment.

Core domains are the areas where you want to do something different that will give you a competitive edge. For your pizza company, that might be how you present the menu, collect customizations, and offer deals and rewards.

Non-core domains, also called generic domains, are areas where innovation and differentiation make little difference, or where doing things differently may even be undesirable. Customers expect that looking up their address and paying will work like elsewhere. They don’t want you to be innovative here, as it makes it harder to use.

So, core domains are something unique or special to your organization. It’s essential to your business’s existence, and where you should invest the most. This is something you want to do so well that it’s hard for your competitors to copy.

The problem of generic domains

When you spend time on generic domains, you direct time, attention, energy, and investment away from the areas that impact your organization most. Generic domains have limited value because they don’t benefit from doing something different or unique. The pizza company will never create such an excellent payment flow that you’d choose their offering over a competitor who offers better customization.

Generic domains can be just as complex as your core domains, which means they can consume large amounts of investment. Suppose there’s a commercial provider of an offering in your generic domain space. In that case, they’ll be treating it as a core domain and innovating the space, which puts additional pressure on you to invest to avoid falling behind user expectations.

Organizations that avoid the generic domain trap can outpace their competitors as they spend more time working on features that will make them stand out.

How to tame generic domains

There’s an easy way to avoid the generic domain trap. Domain-driven design provides a pattern for managing them, which recognizes the asymmetry in the value gained by investment in core domains versus generic domains.

Instead of reducing costs on paper, the goal is to minimize the real cost of working on generic domains: Lost value.

You should work through this list from the top and choose the earliest exit available.

1. Off-the-shelf: Look for existing software or services that address the generic domain. In particular, look to use:
   1. Commercial products and software-as-a-service offerings where the provider treats it as a core domain. Their innovation and support will ensure the generic domain doesn’t become an anchor dragging you back.
   2. Open source tools that are robust and maintained, and where the overheads of adopting and updating them are low.
2. Isolation: Where you have to build custom code for a generic domain, encapsulate and isolate it. Placing it behind a well-defined interface minimizes the impact on your core domain and lets you switch it out if an off-the-shelf solution emerges later.
3. Outsourcing: While outsourcing your core domain can cause problems, outsourcing generic domains helps control the cost and distraction of the work. You can define the interface and have an outsourced team focus on the implementation details.
4. Minimalism: When no other option is available, create a simple minimalist solution that meets the immediate need. Don’t over-engineer the generic domain or add features you don’t need. You can be reluctant to iterate the solution and keep your eyes and ears open for when someone creates a software product or service you can use to replace it.

Analyzing build versus buy

Platform Teams who want to create the most significant force multiplier for the developers they serve need to protect their focus on fitting the tools to the organization. To do that, they need to identify and eliminate areas where their skills are wasted.

A crucial part of this optimization process is performing a solid build versus buy analysis, which should factor in the initial development cost, ongoing maintenance and support costs, and the opportunity cost of diverting resources away from the core domains.

Returning to the pizza restaurant, offloading the address lookup to a vendor that commonly provides this feature will mean users are familiar with how it works. The vendor will dedicate more attention to improving the user experience of their tool, and when the vendor introduces innovations, they appear commonly enough that users accept them.

Similarly, you’d want to offload payments to a fast and secure payment provider. Hence, it works like other sites and keeps pace with developments like 3D secure, tokenization, card security codes, multi-factor authorization, and biometrics. These industry innovations would have forced the developers to revisit this generic domain many times just to keep pace with the baseline.

Why this is crucial for Platform Engineering

Domain-driven design (DDD) tells us to optimize our development efforts where they will have the most impact on the organization’s success. You shouldn’t over-invest in non-core domains, as they have limited business value and drain resources. Building custom solutions for non-core domains brings unnecessary complexity and maintenance burden, and for what? To build something that you could have bought or outsourced.

The software industry is about to re-learn the lessons that led to the discovery of domain-driven design. Industry-wide, we are dedicating thousands of developers to building the same thing. Not a simple minimalist solution to fill a gap left by commercial products, software-as-a-service, or open source software, but a million giant platforms that are out of date before they’ve been pushed to production.

Internal developer platforms sink unless platform teams can shift weight down to underlying tools. By transferring ballast to commercial products or open source tools, the platform team can get back to agility and create simple, minimal solutions that handle real gaps in toolchains caused by truly bespoke needs.

And it’s these very needs that are missed with behemoth platforms. An organization that needed to go an extra two miles on security may adopt Platform Engineering to tailor a truly robust solution to their security needs. As that platform grows and accumulates additional custom features, the focus on security is lost, and the investment is wasted building and maintaining code that doesn’t solve a unique need for the organization.

But it’s not all doom and gloom for Platform Engineers. Commercial and open source tools can rescue them from this inevitability by providing features that make it easy to shift the weight down and keep the platform light enough to float.

Float on our Platform Hub

That’s where Platform Hub comes in. By adding features platform teams need, like process templates, project templates, and policies, platform teams can transfer the effort down to Octopus and lighten their platform by removing thousands of lines of bespoke templating code.

Platform Teams can get back to focusing on the unique needs that make their platform vital to their organization. They will benefit from our innovative mechanisms for template management and policies, which go well beyond the attack of the template clones and the synchronization conflicts that platform teams report with their bespoke solutions.

Happy deployments!

Related posts