How to Apply Domain‑Driven Design in a Real‑World Knowledge‑Payment Platform

Background

The author started learning Domain‑Driven Design (DDD) in 2018 after reading Eric Evans' seminal book, but felt confused; later read Vaughn Vernon's "Implementing Domain‑Driven Design" and applied its concepts to a virtual company called Smart Classroom (a knowledge‑payment product named by ChatGPT). The article aims to share the author's understanding and help readers practice DDD.

Why Write This Article

To record personal insights after a long learning curve with DDD and to provide a practical example that readers can follow.

Virtual Business Scenario

The fictional company Smart Classroom offers paid knowledge courses. Experts become authors, create column series, and users subscribe to columns. The company shares commission with authors based on contracts.

Code of This Article

The sample code uses popular technologies and does not contain any private data.

Backend microservice 1: https://github.com/eyebluecn/smart-classroom-misc

Backend microservice 2: https://github.com/eyebluecn/smart-classroom-subscription

Frontend project: https://github.com/eyebluecn/smart-classroom-front

Online demo: https://classroom.eyeblue.cn/

Article Structure

The article first introduces DDD basics, then explains strategic and tactical design, followed by two concrete modeling methods (Event Storming and Four‑Color Modeling), and finally presents a full implementation (domain model, sub‑domains, bounded contexts, architecture, diagrams, and coding conventions).

What is DDD

MVC Pattern

Traditional MVC places the model in the database, business logic in the controller (often a service), and the view for presentation. While suitable for simple applications, MVC lacks a shared business language, mixes data and behavior, and makes team boundaries unclear as projects grow.

DDD Definition

Domain‑Driven Design is a model‑driven approach that captures domain knowledge in a domain model, making software easier to maintain.

Value of DDD

Ubiquitous Language

All stakeholders (business, product, design, tech) deliberately use a common set of terms within a bounded context, improving communication and efficiency.

Business‑Driven Modeling

Separates business complexity from technical complexity by focusing on the domain model and keeping technical details out of it.

Clear‑Boundary Design Method

Identifies domains, sub‑domains, and bounded contexts to guide team division and micro‑service decomposition.

Business Knowledge Consolidation

Iteratively refines the model so that it stays aligned with the real world, allowing knowledge to be transferred and preserved.

Basic Concepts of DDD

Ubiquitous Language

Using the "Smart Classroom" example, the term "User" refers to anyone registered in the system, "Subscription" denotes a paid column, etc.

User (User) – a registered person.

Subscription (Subscription) – a column the user has paid for.

A user can subscribe to multiple columns.

Subscription – the bounded context.

Strategic Design

Domain

A domain is the whole business area of an organization. In the example, the domain is "knowledge‑payment".

Subdomain

Independent business areas within a domain, such as subscription, finance, and column management.

Core, Generic, and Supporting Subdomains

Core Domain : Directly creates business value (e.g., subscription domain).

Generic Domain : Common functionality used by many subdomains (e.g., authentication, authorization).

Supporting Domain : Specific to the business but not core (e.g., column, comment).

Bounded Context

A logical boundary that groups related subdomains; each bounded context maps to a micro‑service. Example: "Column Subscription Context" contains order and subscription subdomains.

Tactical Design

Entity

Objects with a unique identifier and lifecycle, e.g., Column, CourseArticle, Subscription.

Value Object

Objects identified by their attributes, immutable, e.g., Money, Address.

Aggregate & Aggregate Root

Cluster of entities/value objects with a single root entity that controls external access.

Factory

Creates complex objects or aggregates, encapsulating creation logic.

Repository

Abstraction for data access, keeping the domain layer independent of persistence details.

Domain Service

Encapsulates domain operations that do not naturally belong to an entity or value object, such as the "Subscribe" behavior that touches multiple entities.

Domain Event

Significant occurrences within the domain that can trigger other actions, often delivered via message queues.

Domain Modeling

Event Storming Modeling

Introduction

Event Storming captures business events (e.g., Payment Started, Paid) and links them to commands, policies, actors, and read models. It uses colored sticky notes to visualize the flow.

Syntax

Actors (yellow)

Commands (blue)

Events (orange)

Systems (purple)

Read Models (green)

Policies (pink)

Hotspots (red)

Process (using the subscription flow as example)

Preparation : Gather materials, invite participants.

Opening Introduction : Explain Event Storming, its benefits, and the scope.

Step 1 – Identify Events : Place orange notes for events like "Column Subscribed" and ask what happened before/after.

Step 2 – Business Rules : Use pink notes to capture rules such as "Order must be paid before subscription".

Step 3 – Actors, Commands, Read Models, Systems : Use yellow, blue, green, and purple notes to map who triggers what and what data is needed.

Step 4 – Hotspots : Mark unclear or risky points with red notes.

Step 5 – Storytelling : Walk through the timeline to verify consistency.

Step 6 – Architecture Output : Derive domain model, use‑case diagram, state diagram, etc.

Four‑Color Modeling

Introduction

Originating from Peter Coad’s color modeling, the method adds four colors to represent cash flow, cost structure, and KPI‑driven events, providing a more analytical approach.

Syntax

Four colors correspond to four object prototypes (actors, commands, policies, events) and are used to trace business evidence (receipts, vouchers).

Process (using the same "Smart Classroom" example)

Identify key cash flows (payment, commission) and create vouchers.

For each voucher, trace upstream data sources (user input, previous vouchers, calculations).

Determine rights and obligations linked to each voucher.

Document all key data items for each voucher.

If no cash flow, use KPI indicators as the basis.

After establishing the voucher chain, map roles, participants, and objects.

Refine the domain model from the voucher chain.

Validate the model by simulating normal and exceptional scenarios.

Practical Implementation

Domain Model

After the modeling steps, the following simplified domain model is obtained (illustrated in the original diagram).

Sub‑Domain Division

Sub‑domains are aligned with aggregates to keep boundaries clear.

Core Domains: Order, Subscription

Supporting Domains: Column, Column Pricing, Finance, Contract, Commission

Generic Domains: Reader, Editor, Author

Bounded Context Division

Each bounded context becomes a micro‑service. The example yields five services: Column Subscription, Column Information, Contract & Commission, Finance, and User Information.

Key Diagrams

Use‑Case Diagram (Subscription System) –

State Machine –

Activity Diagram –

Sequence Diagram (Subscribe) –

ER Diagram –

Solution Design (Application Architecture)

The system is split into two backend applications for demonstration: smart‑class‑subscription (the core subscription micro‑service) and smart‑class‑misc (the aggregation of other contexts). The technology stack includes Spring Boot, MyBatis, MySQL, Dubbo, Nacos, RocketMQ, and Maven.

Layered Module Structure (COLA‑inspired)

Facade : API definitions (write/read).

Facade‑Impl : Implementation, request/response conversion.

Application : Orchestrates domain services, handles transactions, queries, domain events, logging, security.

Domain : Entities, value objects, domain services, aggregates, repository interfaces, factories, anti‑corruption interfaces.

Repository : Persistence logic (MyBatis mappers, DO objects).

Infrastructure : RPC clients, message‑queue clients, external service adapters.

Utility : General purpose helpers, exception definitions.

Coding Conventions

POJO Naming : DO (Database Object), Model (Domain Object), DTO (External Transfer Object), Info (Internal Transfer Object), VO (Value Object), Query, Request, Converter.

Bean Naming : Controller, Facade, FacadeImpl, AppService, DomainService, Repository, RepositoryImpl, Client, ClientImpl, Configuration.

Method Naming : queryXxx (single), listXxx (multiple), pageXxx (paged), countXxx, insertXxx, deleteXxx, updateXxx.

Conversion : Write explicit field‑by‑field converters; avoid BeanUtils or MapStruct.

Saber Tool

Saber automatically generates MyBatis Mapper and DO files from database metadata, reducing manual boilerplate.

Project Demo

Backend microservice 1: https://github.com/eyebluecn/smart-classroom-misc

Backend microservice 2: https://github.com/eyebluecn/smart-classroom-subscription

Frontend project: https://github.com/eyebluecn/smart-classroom-front

Online demo: https://classroom.eyeblue.cn/

The demo allows two roles: readers and editors. Editors can create columns; readers can subscribe and view subscribed columns.

Conclusion

Domain‑Driven Design is a mindset rather than a rigid template. It helps teams capture business knowledge, build a shared language, and keep high cohesion with low coupling. While DDD is not a silver bullet for simple projects, it provides valuable tools—strategic design, tactical patterns, event storming, and four‑color modeling—for tackling complex domains.

Acknowledgements

The article draws on many prior works, including Eric Evans, Vaughn Vernon, Xu Hao, and various Alibaba technical blogs.

References

Eric Evans, "Domain‑Driven Design"

Vaughn Vernon, "Implementing Domain‑Driven Design"

Xu Hao, "How to Apply Business Modeling"

Erich Gamma, "Design Patterns"

EventStorming: https://www.eventstorming.com/

Other links as listed in the original source.