Applying Domain-Driven Design and Architecture Mapping in a Video Membership System: Process, Modeling, Refactoring, and Evaluation

This article explores how Domain-Driven Design (DDD) can be combined with architecture mapping to address complex business and technical challenges in a video membership system.

1. Introduction

The guiding philosophy of DDD is often abstract, making it hard to relate to real‑world architecture scenarios. By introducing architecture mapping, the article proposes a quantitative evaluation method and demonstrates its application through a Tencent video‑watching system case study.

2. Domain‑Driven Design Overview

DDD aims to bridge product requirements and system implementation through domain modeling. The video membership project faces high business complexity (playback, purchase, activities, content interaction) and technical complexity (business rules, many modules, high request volume, security). The article outlines four core DDD methods and presents two concrete domain‑model examples for content display, interaction, cooperation, and innovation.

3. Software Architecture

Software architecture is described via structure, architectural features, decisions, and design principles. Common architectural features include availability, scalability, fault tolerance, performance, and maintainability. Six typical architecture styles are listed: layered, pipeline, micro‑kernel, microservices, event‑driven, and compile‑driven.

4. Architecture Mapping

Architecture mapping translates domain models into system architecture. The process includes extracting core concepts from product requirements, building a domain model (often visualized with domain or ER diagrams), mapping the model to a layered micro‑service architecture, and detailing module responsibilities before coding.

5. Refactoring Strategy

The existing “together‑watch” system accumulated technical debt due to unclear layering, duplicated responsibilities, and monolithic modules (e.g., room_adapter ). The refactoring plan proposes:

Clarifying architecture layers and eliminating unnecessary coupling.

Re‑dividing domains to achieve high cohesion and low coupling.

Splitting large modules into focused, reusable components.

Post‑refactoring, the system transitions from a micro‑kernel style to a clean micro‑service architecture, improving testability, extensibility, and modularity.

6. Effect Evaluation

Both qualitative and quantitative analyses are performed. Qualitatively, the refactored system moves from a monolithic, hard‑to‑maintain architecture to a modular micro‑service design. Quantitatively, metrics show:

Code size reduced by 55% (from ~40k lines to ~18k lines).

Top‑4 API latency decreased by ~45%.

Cost reductions of ~40% for specific services.

Improved architectural feature scores (e.g., modularity, cohesion).

7. Key Design Points

The article summarizes the system’s core data structures, technical and business indicators (e.g., peak QPS ~30k, Redis usage 11.16 GB, total online rooms ~6k), and highlights the importance of integrating architecture theory with practical design to achieve measurable improvements.