It’s safe to say that almost all software projects require the collaboration of stakehold‐ ers in different roles: domain experts, product owners, engineers, UI and UX design‐ ers, project managers, testers, analysts, and others. As in any collaborative effort, the outcome depends on how well all those parties can work together. For example, do all stakeholders agree on what problem is being solved? What about the solution they are building—do they hold any conflicting assumptions about its functional and non‐ functional requirements? Agreement and alignment on all project-related matters are essential to a project’s success.

1 Brandolini, Alberto. (n.d.). Introducing EventStorming. Leanpub.

Research into why software projects fail has shown that effective communication is essential for knowledge sharing and project success.2 Yet, despite its importance, effective communication is rarely observed in software projects. Often, businesspeo‐ ple and engineers have no direct interaction with one another. Instead, domain knowledge is pushed down from domain experts to engineers. It is delivered through people playing the role of mediators, or “translators,” systems/business analysts, prod‐ uct owners, and project managers. Such common knowledge sharing flow is illustra‐ ted in Figure 2-1.

Figure 2-1. Knowledge sharing flow in a software project

During the traditional software development lifecycle, the domain knowledge is “translated” into an engineer-friendly form known as an analysis model, which is a description of the system’s requirements rather than an understanding of the business domain behind it. While the intentions may be good, such mediation is hazardous to knowledge sharing. In any translation, information is lost; in this case, domain knowledge that is essential for solving business problems gets lost on its way to the software engineers. This is not the only such translation on a typical software project. The analysis model is translated into the software design model (a software design document, which is translated into an implementation model or the source code itself). As often happens, documents go out of date quickly. The source code is used to communicate business domain knowledge to software engineers who will maintain the project later. Figure 2-2 illustrates the different translations needed for domain knowledge to be implemented in code.

2 Sudhakar, Goparaju Purna. (2012). “A Model of Critical Success Factors for Software Projects.” Journal of Enterprise Information Management, 25(6), 537–558.

Figure 2-2. Model transformations

Such a software development process resembles the children’s game Telephone:3 the message, or domain knowledge, often becomes distorted. The information leads to software engineers implementing the wrong solution, or the right solution but to the wrong problems. In either case, the outcome is the same: a failed software project.

Domain-driven design proposes a better way to get the knowledge from domain experts to software engineers: by using a ubiquitous language.