Domain-Driven Design: Problem Domain Analysis and Modeling in Bilibili OGV Business

This article presents a comprehensive overview of Domain‑Driven Design (DDD) as a thinking method for tackling software core complexity. It begins with a discussion of why complexity arises from scale, structure, and change, citing Eric Evans and the philosophy that complexity is anything that makes software hard to understand or modify.

The author explains how DDD introduces a set of design meta‑models (bounded contexts, context mapping, domain services, events, entities, value objects, etc.) to control system scale, clarify structure, and respond to change. The benefits and shortcomings of DDD are examined, noting the lack of a unified process and the reliance on designers' expertise.

Using Bilibili’s OGV (Online Video) business as a concrete example, the article walks through the problem‑domain analysis phase of DDD. It describes the value‑demand analysis method, identifying stakeholders (beneficiaries and supporters) and mapping them to a business vision and constraints. The business‑demand analysis follows, focusing on user‑oriented functional requirements, business processes, and business scenarios.

Key steps include:

Extracting value demands through stakeholder interviews, business‑vision analysis, and the 5W model.

Deriving business demands by constructing end‑to‑end business process diagrams and use‑case diagrams.

Identifying business scenarios from processes or directly from service requests, emphasizing the “who‑where‑when‑why‑what” structure.

The article also stresses the importance of a ubiquitous language shared by domain experts and developers, and outlines how to capture and document it throughout the analysis, design, and coding phases.

Sub‑domain identification and classification (core, generic, supporting) are detailed, with criteria such as business function, product line, process stage, and domain concepts. A sub‑domain mapping diagram (Figure 4‑1) illustrates the OGV business’s major sub‑domains and bounded contexts.

In the summary, the author notes that the current piece only covers problem‑domain analysis; future articles will address architectural patterns, implementation details, and concrete modeling techniques.