How DDD Reshapes Video Platform Architecture: A Quantitative Refactoring Study

Domain‑Driven Design Overview

The video membership team at Tencent Cloud embarked on a DDD‑driven project to reorganize the entire technical system of the "Together Watch" product. The goal is to use DDD methods to clarify business complexity, cross‑department collaboration, system taxonomy, and to visualize the domain model.

1. DDD Introduction

Key challenges identified include:

Complexity : both business (playback, purchase, activities, content display, interaction) and technical (rules, many modules, high request volume, security).

Cross‑department collaboration : involves membership, live‑stream platform, Tencent Cloud, security review, etc.

System taxonomy : content display, interaction, cooperation, innovation.

Domain model : the article focuses on using domain diagrams to present the membership content system intuitively.

The core DDD methods are summarized in four points (illustrated below):

2. Domain Modeling

After understanding product requirements, core concepts are extracted and organized into a logical structure— the domain model—typically expressed as a domain diagram or ER diagram. This abstraction helps grasp complex business logic.

Applying the "big fractal" principle (divide‑and‑conquer), a preliminary domain model for the content system is built.

Example 1: Content Sub‑domains

Content Display : channel pages, bottom‑layer pages, external channel pages.

Content Interaction : watch‑together, drama, chat, gifting, linked mic, companion watch.

Content Cooperation : novels, comics, paid knowledge.

Content Innovation : NFT, etc.

Example 2: Architecture Diagram

3. Software Architecture Fundamentals

Software architecture can be described by four dimensions: structure, architectural features, architectural decisions, and design principles.

Structure : architectural styles such as layered, micro‑service, pipeline, event‑driven.

Architectural Features : qualities like availability, scalability, fault‑tolerance, performance, maintainability.

Architectural Decisions : concrete rules, e.g., presentation layer may only access the logic layer.

Design Principles : guidelines such as preferring asynchronous messaging between services.

Architectural Features Classification

Features are divided into operational and structural categories.

Implicit Feature: Modularity

Modularity is often praised but rarely defined. It is essential for maintainable systems, influencing cohesion, coupling, and symbiosis.

4. Architecture Mapping

DDD Process Model

Extract core concepts from product requirements → build domain model.

Map domain model to system architecture (usually a layered micro‑service architecture).

Detail each architectural module (process flow, data structures, DB tables) before coding.

Why Architecture Mapping Matters

Many projects start directly with architecture design, skipping domain modeling because the business appears simple or UI design substitutes for modeling. Only complex domains truly benefit from a full mapping.

5. Refactoring Strategy

Motivation

The "Together Watch" system accumulated technical debt after years of feature additions across two cross‑department teams, resulting in a lack of unified design.

Refactoring Plan

Clarify architecture layers; eliminate unnecessary coupling.

Re‑divide domains to balance module size.

Logical Refactoring

Extract non‑core logic into separate sub‑domains.

Create reusable components to avoid code duplication.

Example: room_adapter mixed business logic, scheduled tasks, callbacks, auth, and messaging, making it hard to maintain.

Solution: isolate business logic in room_adapter, move other concerns to dedicated modules or trpc interceptors.

6. Quantitative Effect Evaluation

Qualitative Improvements

Before: monolithic, hard to maintain and scale.

After: micro‑service, simple kernel, easy to extend.

Before: feature pile‑up without planning.

After: clear architecture, orderly feature expansion.

Quantitative Metrics

Architecture level : shifted from micro‑kernel to micro‑service pattern.

Module level : room_adapter reduced to pure room logic; other concerns split into small, high‑cohesion modules.

Code level : lines of code dropped from ~40k to ~18k (‑55%).

Performance : top‑4 interface latencies improved ~45% on average.

Cost : major services (PCG‑123, CLS) saw ~40% cost reduction.

Relevant charts are shown below:

7. Key Design Highlights

System Architecture : layered micro‑service design with clear responsibilities.

Core Data Structures : illustrated with diagrams (omitted for brevity).

Technical Indicators : peak QPS ≈ 30k, Redis usage 11.16 GB.

Business Indicators : total online rooms ≈ 6 k (user rooms ~3 k, system rooms ~3 k, operation rooms ~0.25 k).

8. Final Thoughts

The article raises four open questions addressed through the case study:

How to provide a unified quantitative analysis framework for architecture evaluation.

How domain modeling and architecture design relate via the "architecture mapping" concept.

How to combine architectural theory with practical design to produce actionable, comparable methods.

How to present refactoring outcomes in a quantifiable, integrated manner rather than isolated qualitative statements.