Prioritizing DDD Modeling: Focus on Domains, Subdomains, and Core Domains

1. Plain Language: What Are Domains and Subdomains

Domain is the business your company does. In the "Preferred Store" example, the domain is "store retail e‑commerce". Because a domain is too large to handle at once, it is broken into smaller pieces called Subdomains , analogous to a company's departments such as sales, warehousing, finance, and HR.

The "Preferred Store" project splits into subdomains like product, inventory, order‑transaction, promotion, membership, payment, and delivery.

Importantly, these subdomains are not equal.

2. Core, Supporting, and Generic Subdomains (The Most Practical DDD Classification)

This is the most cost‑effective tool in DDD strategic design: it tells you to put money and the strongest people on the blade‑edge.

Subdomains are divided into three categories:

Core Domain – The Profit‑Driving Heart

The core domain is the business that differentiates you from competitors and determines success; it is your moat.

For "Preferred Store", the core domains are order‑transaction and promotion :

Order‑transaction directly generates revenue; conversion rate and fulfillment experience decide the business.

Promotion is the key weapon of retail e‑commerce – effective discounts, coupons, and flash sales directly affect GMV, and a more flexible competitor promotion can steal users.

Core domains should receive the strongest team and the most precise DDD modeling. The later chapters on aggregates, domain events, and CQRS are mainly for core domains.

Supporting Subdomain – Necessary but Not Competitive

These are required for the business but cannot make you win; they only keep you from losing.

In "Preferred Store", product management, inventory, and delivery are supporting subdomains.

Products must exist, inventory must be accurate, and goods must be deliverable – all are indispensable.

However, a "super‑powerful product‑management system" does not become a competitive advantage; it only needs to be "good enough and stable".

Supporting subdomains can be implemented with relatively simple solutions, even outsourced or bought off‑the‑shelf; there is no need for the most complex modeling.

Generic Subdomain – Same for Everyone, Buy If Possible

These are highly standardized business functions that every company needs.

For "Preferred Store", payment, message notification, and reconciliation are generic subdomains.

Payment: integrate directly with WeChat Pay, Alipay, UnionPay.

SMS notification: purchase a third‑party service.

Building a payment system from scratch is a waste of effort – it is not your competitive edge.

Generic subdomains should prioritize existing solutions (third‑party services, open‑source components, SaaS) rather than reinventing the wheel.

3. One‑Page Diagram of the "Preferred Store" Subdomain Division

4. Why This Division? Benefits Compared with Traditional Approaches

Drawbacks of Traditional Projects

Traditional projects treat all modules equally: product management receives the same manpower as order‑transaction, and teams attempt to build a "better" payment system from scratch. The results are:

Senior engineers are wasted on supporting domains like product category management, while the core promotion engine receives only cursory attention.

Self‑built payment and SMS gateways create non‑competitive wheels and introduce hidden pitfalls.

The whole system is uniformly stressed, leading to a lack of core competitive advantage and over‑investment in secondary areas.

Advantages of the Domain‑Based Division

Resource Focus : Deploy the strongest people and the most detailed modeling to core domains (order, promotion) to deepen the moat.

Cost Reduction & Speed : Supporting domains only need to be adequate; generic domains are bought off‑the‑shelf, freeing time for core domains.

Decision Basis : Whether to build in‑house, outsource, or use a complex architecture is answered by the subdomain classification.

5. Common Pitfalls

Core domains are not static . Early on, "Preferred Store" might consider product richness as core; later, promotion and fulfillment efficiency become core. Re‑evaluate regularly.

Don’t equate technical difficulty with core status . Search technology may be hard, but if it isn’t a key differentiator, treat it as a supporting domain and use existing solutions like Elasticsearch.

Keep core domains small and focused . Declaring everything as core eliminates the concept of a core.

6. Next Step in DDD

After subdomain division, the most important yet often underestimated concept is the Bounded Context . Subdomains provide a business‑level view; bounded contexts define the software‑design boundaries where those subdomains are implemented. The next chapter covers this.