Applying Domain‑Driven Design: Achieving Consensus and Effective Team Collaboration

Author Bio: Zhang Yi, former senior software engineer, architect, technical director, and chief consultant at ZTE, HP GDCC, Chinasoft International, ThoughtWorks, etc. Prolific author of popular GitChat courses. Skilled in Java, Scala, Python, C#, JavaScript, Ruby and experienced in OOP, TDD, refactoring, DDD, functional programming, architecture, big‑data analysis, agile, and process improvement, focusing on service‑oriented, big‑data, and web system architecture. Publications include "Essentials of Software Design and Patterns", "Java Design Patterns", "Appropriate Software Architecture", "WCF Service Programming", and annotated editions of "Refactoring" and "Beautiful Architecture".

The core of Domain‑Driven Design (DDD) is the "domain"; therefore, teams must start by correctly identifying the problem domain. After forming the team, the highest priority is not UI prototyping, architecture design, or database design, but establishing a shared understanding of the domain.

If a project begins without consensus on system goals and scope, the development direction will drift over time.

Using DDD means first recognizing the problem domain and then extracting consensus‑based domain knowledge for the team.

Requirements are not pre‑existing trees; they are seeds that need soil, sunlight, and water—i.e., collaborative cultivation with the customer.

Achieving Consensus

Cultivating requirements requires two‑way communication and feedback to reach a common understanding of domain knowledge. Without proper communication, each stakeholder may hold a different "Hamlet" of the requirement, creating an illusion of agreement.

Because participants have different information, backgrounds, and contexts, they often resemble blind people feeling an elephant—each perceives only a part of the whole.

Traditional contracts try to lock requirements in a heavy specification document, but any change beyond its boundaries triggers a formal change‑request process, which is fragile because of three common misunderstandings:

What we hear from the client is not the end‑user's real need.

Lack of effective communication leads to divergent interpretations.

Partial understanding creates cognitive gaps in domain modeling and design.

Jeff Patton’s comic in "User Story Mapping" illustrates how visual collaboration helps multiple roles converge on a shared view.

Visual tools—drawings, sticky notes, user stories, or test cases—make hidden assumptions visible and reduce cognitive bias.

When differences are clarified, team members can complement each other's knowledge, discard redundancies, and converge on a unified model.

Team Collaboration

Collaboration methods differ across software development stages. During the Inception phase, the team knows nothing about the project; communication with customers or domain experts should focus on high‑level vision, boundaries, and core business processes, and on establishing communication channels with stakeholders.

Inception Phase

In agile projects, the Inception phase is crucial for gathering domain knowledge. Using strategic design, teams create a shared language, identify epic‑level stories, define bounded contexts, and outline logical and physical architectures.

The seven activities shown follow a clear order: identify stakeholders, clarify business expectations and vision, agree on the problem domain, define current and future states, determine business scope, and decompose requirements from epic to master stories within that scope.

Iteration Development Phase

During each iteration, teams communicate around the iteration goal and each task’s domain knowledge, often following Scrum practices.

Scrum’s planning meeting lets the Product Owner explain user stories, business logic, and acceptance criteria. Daily stand‑ups allow the Product Owner to answer questions promptly, while the Scrum Master monitors progress and helps adjust priorities.

At the end of an iteration, a demo involving developers, testers, customers, and domain experts validates the increment against acceptance criteria, reducing misunderstandings.

Each user story is the smallest unit of domain knowledge; its quality directly impacts DDD outcomes.

Agile emphasizes collaboration between analysts and testers to create living documentation—automated acceptance tests that capture both normal and exceptional scenarios.

When developers receive a user story, they should hold a brief “kick‑off” with analysts and testers to clarify the story’s value before coding.

After development, a quick “desk check”—a mini demo in the development environment—lets developers walk analysts and testers through the new functionality, verifying it against acceptance criteria before moving the story to “Ready for Test”.

Un‑tested stories deliver no value; they are considered incomplete. Early testing reduces bug‑fix costs, as bugs discovered soon after coding can be fixed quickly.

Frequent communication, solid collaboration, and rapid feedback are essential to keep the domain model aligned with implementation, which are the fundamental prerequisites for practicing DDD effectively.

END