Domain-Driven Design: Core, Supporting & Generic Subdomains

Software succeeds when it solves real-world business problems. To be useful, the software must fit the business's needs and be easy to maintain. In this article, I will explain the basics of Domain-Driven Development and how it helps to design and write better software.

Theory of Domains

Every successful company solves a real customer-facing problem. For example, Spotify solves the problem of limited and expensive access to music. This "core" problem is named Domain. The company may operate in multiple domains; for example, Google provides Cloud Services, Email, YouTube, and AI.

A domain is not something monolithic – it is created from multiple smaller, specific areas, known as subdomains. A subdomain by itself is not enough for a company to succeed – it adds up to the business domain.

Subdomains are not equal. Some can be highly complex, some can be extremely simple. Some can be unique, while some can be similar in every company. This creates three distinct types: Core, Supporting, and Generic.

Generic Subdomains

Generic subdomains are solved problems that all companies do the same way, for example, authentication, push notifications, logging, or a Kanban board. Instead of inventing your own solutions, it is more reasonable to buy or adopt an existing one.

Core Subdomains

Core subdomains offer a competitive advantage. They have a highly complex and unique logic that is difficult to replicate. Companies invest their top resources into core subdomains to make them more performant, cost-efficient, and effective. Examples of core subdomains include: route optimization in Uber, the LLM models of OpenAI, and YouTube's recommendation engine.

You cannot purchase something and make it your core. Otherwise, everyone would be able to do it, and then there would be no competitive advantage. Also, if someone can copy your core subdomain easily, then it has little competitive advantage.

Supporting Subdomains

Supporting subdomains do not offer a competitive advantage for the company. For example, the feature of playlists in Spotify or the ability to add comments on YouTube. These are designed to support main business activities and are tailored to the core domain. For this reason, supporting subdomains usually require custom solutions.

In contrast to generic and core, supporting subdomains should not contain complex business logic as they do not provide a competitive advantage.

Categorization Cheatsheet

I like the categorization approach by Vladik Khononov:

• Can you buy/adopt an off-the-shelf product without compromising the company’s competitive advantage? - Generic Subdomain.
• Is the business logic simple? - Supporting Subdomain.
• Finally, if you can’t buy a product, and the subdomains’ business logic is complex, then it’s a Core Subdomain.

Perspective Matters

An authentication system is a generic subdomain for the business that adapts an off-the-shelf solution. However, for a company that builds the solution, it is its core domain. The same works for other types of domains. For example, the in-app messaging functionality of an e-commerce app is absolutely its supporting subdomain. At the same time, it is a core domain of a messaging app.

Distilling Subdomains

Although top-level subdomains are a good starting point, they may still seem too broad to understand and model in code. For example, let's say Spotify has a subdomain called "Social & Community." That sounds too abstract. If a manager asks a developer what he is working on and the developer answers, "Social & Community," the manager would naturally follow up with, "Which part of it?"

Broad subdomains can (and often should) be broken down further. Spotify's "Social & Community" subdomain, for example, may contain profile management features such as followers, followees, and profile photos; Live Jam, which allows users to listen to music together; and public playlists, among other features.

Figma Case Study

Figma's domain is providing tools for collaborative design development. It can be broken down into two core subdomains:

• Collaborative Engine: This technology allows multiple users to edit a single file simultaneously, solving version control issues.
• Canvas & Editor: The high-performance, design editor itself, including its proprietary vector networks and rendering engine.

You might wonder why the Real-Time Collaborative Engine is listed as the primary core subdomain, above the editor. The reason is simple: collaboration is what made Figma revolutionary.

Before Figma, the market was filled with tools like Sketch and Adobe XD. However, they were single-player experiences that made teamwork cumbersome. Figma's breakthrough was not just building another editor, but building one that was collaborative from the ground up.

Supporting Subdomains:

• Prototyping & Interaction: Tools to create interactive, clickable mockups from static designs.
• Community & Plugin Ecosystem: An API and platform allowing third parties to extend Figma's functionality and share design files.
• FigJam: An adjacent product for brainstorming that leverages the core collaborative engine.

Generic Subdomains:

• Payments / Billing - They rely on Stripe for subscription billing and payment processing.
• Storage - Figma stores all files in an AWS S3 Bucket with Cloudfront as a CDN.

What is Business Logic?

Each subdomain has essential concepts and rules. For example, the authentication subdomain contains User, Session, Token, and a rule like "password should be min 8 chars." The logistics subdomain contains information like Route, Address, City, and Coordinate, as well as logic that calculates the best way to get from one place to another. These are all examples of business logic contained in subdomains.

In the following article, we will discuss how to effectively model the business logic of a subdomain using ideas from DDD and Clean Architecture.