Why Development Teams Need DDD: Insights, Challenges, and Solutions

At the ThoughtWorks DDD-China 2019 summit, an InfoQ journalist interviewed Zhang Xiaolong, a senior software architect at ZTE, about why development teams need Domain‑Driven Design (DDD) and the challenges of its industry adoption.

Zhang asserts that DDD permeates the entire software development lifecycle—from requirements analysis and modeling to architecture, design, implementation, testing, and refactoring. Code is the core business asset, and development teams are its creators and guardians.

Key practices for development teams include:

Unified language to enable seamless communication across all roles.

All roles working around the domain model .

Standardized layered design —defining how infrastructure, application, DTOs, and domain elements are organized.

In a layered architecture, the application layer handles cross‑cutting concerns such as reporting, alerts, and email notifications, while domain events enable inversion of control so the application layer can react to domain‑layer events.

At ZTE, the core telecom business makes DDD application differ from typical internet companies: the software is large, feature‑rich, with intersecting characteristics and strict requirements for quality, performance, and reliability.

Practical measures ZTE employs include:

Domain experts collaborating directly with the team.

Coaching, training camps, and regular reviews.

Adopting design techniques like DCI, DSL, orthogonal and compositional design, adhering to coding standards, applying embedded C/C++ best practices, maintaining continuous delivery pipelines, and conducting daily code reviews.

DDD's Dilemmas

Recent enthusiasm for DDD has created misconceptions, such as why implementations stall or devolve into agile‑like processes.

Zhang identifies five major dilemmas:

The narrow range of domain case studies, mostly from internet sectors, with little coverage of industrial, embedded, or OS domains.

Scarcity of DDD books, most of which target Java or C#; developers using C, C++, Python, or Go lack suitable references.

Major tech giants rarely organize or sponsor DDD conferences, limiting industry guidance.

Difficulty finding or maintaining communication with domain experts, leading to practice drift.

High skill and competency thresholds required for DDD adoption.

To address these, Zhang recommends:

Training in OOA, OOD, and OOP fundamentals with hands‑on practice to bridge skill gaps.

Ensuring domain experts work closely with the team to keep a shared mental model.

Producing documentation for DDD models that evolves alongside code, enabling newcomers to grasp the full design.

Software development has no silver bullet; DDD is not a universal solution. Teams that choose to follow DDD must stay current with the times and fully understand the new wine in the old bottle.