About a decade ago, Eric Evans presented domain-driven design (DDD) as a new approach to software development in his popular book, Domain-Driven Design: Tackling Complexity in the Heart of Software.

At first, DDD sounded like quite a promising approach, an extremely alluring one for developers working on complex projects. In DDD, once you understand the business domain your software is to address, all you need to do is build a layered architecture where the business logic is split into two distinct modules: core domain logic (which is invariant to use cases) and the application logic (which is the implementation of use cases).

DDD has an analytical portion made of artifacts such as ubiquitous language, bounded contexts, and context mapping; and it has a strategic part made up of aspects strictly related to the supporting software architecture and implementation. The popular rich domain model is just one of many other possible supporting architectures. (A system based on a rich domain model is not inherently better than a plain CRUD system as long as both systems fulfill requirements. The complexity of software stems primarily from the complexity of the underlying business problem.)

The scenario for which DDD provides invaluable help is understanding the intricacies of the business domain. The name of the approach therefore couldn't be more appropriate: domain-driven design. In terms of ROI, the analytical part of DDD is greater than that of the supporting architecture. DDD's ubiquitous language gives a method to learn about key terms -- nouns, verbs, adverbs -- used in the business by business experts. By building such a vocabulary, architects and developers can detect when, even within the same company, the language changes and the same term is used to mean different things or to refer to different aggregates of data.

Such a case forms a bounded context -- an area of the final system that exists on its own, much like a black box connected to the rest of the system. Context mapping is the graph that connects contexts together. Each context has its own language, an independent implementation, and an interface to talk to other bounded contexts. The entire system results from the composition of bounded contexts. The ultimate purpose of DDD is having bounded contexts emerge clearly and unequivocally out of gathered requirements.

Read the rest of this article on Dr. Dobb's.