Subdomains matter because not every part of the system deserves the same modeling investment.

DDD distinguishes core, supporting, and generic subdomains to help teams decide where deep modeling effort should go. The idea is not to glorify some areas and ignore others. It is to spend design attention proportionally to business importance and uniqueness.

OOAD landing page Learning roadmap Previous: Context Mapping Patterns Next: Event Storming

Why This Topic Matters

Why it matters in real Java systems

In an e-commerce platform, pricing or fulfillment optimization may be strategically important, while authentication or commodity reporting may be generic or supporting. Treating them all the same can waste effort in one place and underinvest in another.

Core Explanation

The main design idea

Core subdomains are central to the product's competitive advantage or identity. Supporting subdomains matter operationally but are not the core differentiator. Generic subdomains solve common problems many organizations share. The classification affects where to invest deep domain collaboration and where to buy, reuse, or simplify.

This helps teams stop over-modeling everything equally and start modeling according to business value.

Concept Breakdown

Key ideas to keep in mind

Concept

Core

Where the business gains distinctive value and where careful modeling often pays off most.

Concept

Supporting

Necessary business capabilities that may still need good design but are not the main differentiator.

Concept

Generic

Common capabilities often better standardized, reused, or bought rather than modeled from scratch.

Example classification

Core

Fulfillment promise and inventory reservation

If fast reliable delivery is a differentiator, this is worth deep modeling.

Supporting

Customer support case workflow

Important to operations, but maybe not the main strategic differentiator.

Generic

Authentication or basic document storage

Usually better standardized than treated as a unique modeling frontier.

Practical gain

Invest attention wisely

Not every area needs the same DDD depth, team energy, or architectural purity.

Java Example

Java example in the Order Management domain

Java example: signaling domain priority through modules

package org.javaomnibus.ecommerce.fulfillment.core;

public final class ReservationPolicy {
}

package org.javaomnibus.ecommerce.identity.generic;

public final class AuthenticationProviderAdapter {
}

Code Walkthrough

Step by step

The naming here reflects investment thinking, not only technical grouping.
Core areas deserve more modeling attention and protection.
Generic areas are often better treated as standardized capabilities.
This mindset changes where architectural energy goes.

Real-World Usage

Where this helps in practice

Prioritizing where to spend domain expert time
Choosing which capabilities deserve custom modeling versus standard solutions
Explaining why not every module gets equal design ceremony

Trade-Offs

Trade-offs and when to be careful

Classification helps focus, but it can also become political if teams confuse importance with prestige.
Core today may become supporting tomorrow, so the classification should evolve with the business.

Common Mistakes

Frequent mistakes to watch for

Calling everything core because every team believes its area is special
Underinvesting in a truly differentiating capability because it looks technically ordinary
Over-modeling generic capabilities instead of standardizing them
Forgetting that supporting domains still need coherent design

Related concepts

Bounded contexts When not to use DDD Monolith vs modular monolith vs microservices