Domain-driven design (DDD) is an approach to software development for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:
- placing the project’s primary focus on the core domain and domain logic;
- basing complex designs on a model of the domain;
- initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
Design software by working very closely with the Domain Experts.
Domain-Driven Design is an approach to the development of complex software in which we:
- Focus on the core domain.
- Explore models in a creative collaboration of domain practitioners and software practitioners.
- Speak a ubiquitous language within an explicitly bounded context.
Help by 1) Work closely together 2) documentation 3) Common terms 4) Sit close together
What is the Domain?
domain-driven design we should first establish what we mean by
domainin this context (and in development in general). The common dictionary definition of
domain is: “A sphere of knowledge or activity.” Drilling down a bit from that,
domainin the realm of software engineering commonly refers to the subject area on which the application is intended to apply. In other words, during application development, the
domain is the “sphere of knowledge and activity around which the application logic revolves.”
Focuses on three core principles:
- Focus on the core
- Base complex designs on models of the
- Constantly collaborate with
domain experts, in order to improve the application model and resolve any emerging
The process side of Domain Driven Design involves the collaboration between domain experts, people who know the problem domain, and the design/architecture experts, people who know the solution domain. The idea is to have a shared model with shared language so that as people from these two different domains with their two different perspectives discuss the solution they are actually discussing a shared knowledge base with shared concepts.
Advantages of Domain-Driven Design
- Eases Communication: With an early emphasis on establishing a common and
ubiquitouslanguage related to the
domain modelof the project, teams will often find communication throughout the entire development life cycle to be much easier. Typically,
DDDwill require less technical jargon when discussing aspects of the application, since the
ubiquitous languageestablished early on will likely define simpler terms to refer to those more technical aspects.
- Improves Flexibility: Since
DDDis so heavily based around the concepts of
object-oriented analysis and design, nearly everything within the
domain modelwill be based on an object and will, therefore, be quite modular and encapsulated. This allows for various components, or even the entire system as a whole, to be altered and improved on a regular, continuous basis.
- Emphasizes Domain Over Interface: Since
DDDis the practice of building around the concepts of
domainand what the
domain expertswithin the project advise,
DDDwill often produce applications that are accurately suited for and representative of the
domainat hand, as opposed to those applications which emphasize the UI/UX first and foremost. While an obvious balance is required, the focus on
domainmeans that a
DDDapproach can produce a product that resonates well with the audience associated with that
Disadvantages of Domain-Driven Design
- Requires Robust Domain Expertise: Even with the most technically proficient minds working on development, it’s all for naught if there isn’t at least one
domain experton the team that knows the exact ins and outs of the subject area on which the application is intended to apply. In some cases,
domain-driven designmay require the integration of one or more outside team members who can act as
domain expertsthroughout the development life cycle.
- Encourages Iterative Practices: While many would consider this an advantage, it cannot be denied that
DDDpractices strongly rely on constant iteration and continuous integration in order to build a malleable project that can adjust itself when necessary. Some organizations may have trouble with these practices, particularly if their past experience is largely tied to less-flexible development models, such as the
waterfallmodel or the like.
- Ill-Suited for Highly Technical Projects: While
DDDis great for applications where there is a great deal of
business logicis rather complex and convoluted),
DDDis not very well-suited for applications that have marginal
domaincomplexity, but conversely have a great deal of technical complexity. Since
DDDso heavily emphasizes the need for (and importance of)
domain expertsto generate the proper
ubiquitous languageand then
domain modelon which the project is based, a project that is incredibly technically complex may be challenging for
domain expertsto grasp, causing problems down the line, perhaps when technical requirements or limitations were not fully understood by all members of the team.