The basics of domain-driven design
Bit by Bit
When Eric Evans wrote his book on domain-driven design (DDD) in 2003 [1], he primarily had enterprise software in mind, wherein project teams develop software for various departments. Since then, a vibrant community has been established around DDD that continues to expand the discipline. As a result, DDD has become widespread in the development of software products.
Domain Models
To build software that solves domain-specific problems, development teams condense their understanding of the domain's structures and rules into a domain model that exists in the minds of developers in the form of diagrams, conversations, text, and code. In DDD, the domain model forms the core of a software system. Of course, this core needs to be surrounded by technology (interfaces, persistence, communication, etc.) for the software to be useful.
Building models was not the brainchild of Evans. He drew on object-oriented analysis and object-oriented design and added two essential concepts that solve problems in the design of large systems. In tactical design (more on this later), Evans describes a pattern language (i.e., coherent patterns) that can be used to design domain models.
The larger the scope of a domain model, the more its inconsistencies become visible. The reasons lie in the domain, because many domain concepts can only be meaningfully defined within a specific context, and forcing them into an enterprise-wide model leads to "god classes" and cyclical dependencies – that is, large, cluttered monoliths that are difficult to evolve. Evans proposed developing context-dependent domain models that unambiguously represent concepts and behavior, which leads to functional modularization of the software, or strategic design.
Strategic DDD
Suppose you had to create
...Buy this article as PDF
(incl. VAT)