How DDD and Architecture Mapping Reshaped Tencent Video’s System – A Quantitative Case Study

1. Domain‑Driven Design Overview

DDD concepts are often abstract, making it hard to connect them with real‑world architecture scenarios. By introducing an architecture‑mapping approach, the article proposes a quantifiable evaluation method and demonstrates its application through the Tencent Video “together‑watch” system.

1.1 DDD Introduction

The video‑membership department aims to reorganize its technical stack using DDD. The domain includes playback, purchase, activities, content display, and interaction, all of which increase business and technical complexity.

Complexity: multiple business scenarios and high request volume.

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

Domain modeling goal: visualize the entire content system with domain diagrams.

1.2 Domain Modeling – Example 1

The content system is divided into four blocks centered on content:

Content Display : channel pages, three‑tab bottom‑layer pages.

Content Interaction : watching together, chatting, gifting tickets, co‑watching.

Content Cooperation : novels, comics, paid knowledge.

Content Innovation : NFT etc.

1.3 Domain Modeling – Example 2

Another diagram (omitted for brevity) further refines the domain boundaries.

2. Software Architecture Fundamentals

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

Structure : architectural style (layered, micro‑service, pipeline, event‑driven, etc.).

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

Architectural Decisions : rules such as “presentation layer may only access the logic layer”.

Design Principles : e.g., prefer asynchronous messaging between services.

Architectural decisions have stronger constraints than design principles.

2.1 Architectural Features

Two major categories are operational and structural features. A quote from Myers (1978) emphasizes the long‑standing importance of modularity.

2.2 Architecture Styles and Metrics

The six common styles are layered, pipeline, micro‑kernel, micro‑service, event‑driven, and compilation‑driven. Each style can be rated using the previously defined features.

3. Architecture Mapping

3.1 DDD Process Model

The development process transforms product requirements into a runnable system through product design, domain modeling, architecture design, detailed design, coding, and testing.

Three key steps for DDD (excluding coding) are:

Extract core concepts from requirements and build a domain model (often a domain diagram or ER diagram).

Map the domain model to a concrete system architecture, typically a layered micro‑service architecture.

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

3.2 Mapping Example – “Together‑watch”

Historically, architecture design started directly without domain modeling because:

The business seemed simple (single core entity).

UI mockups often drove architecture decisions.

For complex scenarios, the domain model is first built, then each concept is decomposed into architecture layers.

4. Refactoring the System

4.1 Technical Debt in “Together‑watch”

After years of feature addition by two cross‑department teams, the system accumulated significant technical debt and lacked a unified design.

4.2 Refactoring Plan

Clarify architecture layers; eliminate lower‑layer calls to upper layers.

Redefine domain boundaries to avoid overly large or tiny modules.

4.3 Architecture Refactor

Problems identified:

Unclear layering; lower services contained business logic and called upper services.

Duplicate responsibilities across interfaces/functions.

Redundant code and missing common abstractions.

Solutions:

Enforce strict layering; lower services communicate with upper services only via asynchronous messages.

Re‑divide domains so each module focuses on a single cohesive responsibility.

4.4 Logical Refactor

Key actions:

Strip non‑core logic from the main flow to improve readability.

Extract common components to eliminate code duplication.

Example: the room_adapter module originally mixed room business, scheduled tasks, callbacks, approval, and messaging. After refactor, it only handles room business; other concerns are moved to dedicated micro‑services or interceptors.

5. Effect Evaluation

5.1 Problem & Goal

The goal is to quantify the impact of the refactor across architecture, modules, and code.

5.2 Qualitative Improvements

Before: monolithic, hard to maintain, hard to scale.

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

Before: feature sprawl without overall planning.

After: clear architecture, orderly feature expansion.

5.3 Quantitative Analysis

Using the architecture‑feature metrics, the refactored system is evaluated as a micro‑service style versus the original micro‑kernel style.

Code size : reduced from ~40k LOC to ~18k LOC (55% decrease).

Performance : Top‑4 interface latencies dropped ~45% on average.

Cost : Major cost items (e.g., PCG‑123, CLS) fell ~40%.

5.4 Design Key Points

Clear system architecture with layered micro‑services.

Well‑defined core data structures.

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

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

6. Conclusions

The case study demonstrates that combining DDD with a systematic architecture‑mapping process enables architects to translate abstract domain concepts into concrete, measurable architectural decisions, guide large‑scale refactoring, and produce verifiable improvements in maintainability, performance, and cost.