Domain Driven Design

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?

To define 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 domain and domain logic.
• Base complex designs on models of the domain.
• Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues.

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 ubiquitous language related to the domain model of the project, teams will often find communication throughout the entire development life cycle to be much easier. Typically, DDD will require less technical jargon when discussing aspects of the application, since the ubiquitous language established early on will likely define simpler terms to refer to those more technical aspects.
• Improves Flexibility: Since DDD is so heavily based around the concepts of object-oriented analysis and design, nearly everything within the domain model will 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 DDD is the practice of building around the concepts of domain and what the domain experts within the project advise, DDD will often produce applications that are accurately suited for and representative of the domain at hand, as opposed to those applications which emphasize the UI/UX first and foremost. While an obvious balance is required, the focus on domain means that a DDD approach can produce a product that resonates well with the audience associated with that domain.

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 expert on 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 design may require the integration of one or more outside team members who can act as domain experts throughout 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 waterfall model or the like.
• Ill-Suited for Highly Technical Projects: While DDD is great for applications where there is a great deal of domain complexity (where business logic is rather complex and convoluted), DDD is not very well-suited for applications that have marginal domain complexity, but conversely have a great deal of technical complexity. Since DDD so heavily emphasizes the need for (and importance of) domain experts to generate the proper ubiquitous languageand then domain model on which the project is based, a project that is incredibly technically complex may be challenging for domain experts to grasp, causing problems down the line, perhaps when technical requirements or limitations were not fully understood by all members of the team.

Sources:

Domain-Driven Design – What is it and how do you use it?