Domain-driven design

Domain-driven design (DDD) is a major <a href="/facts/Software_design/61rGr5Ej">software design</a> approach, focusing on modeling software to match a <a href="/facts/Domain_(software_engineering)/NRnAyFlR">domain</a> according to input from that domain's experts. DDD is against the idea of having a single unified model; instead it divides a large system into bounded contexts, each of which have their own model. 
Under domain-driven design, the structure and language of software code (class names, <a href="/facts/Class_method/8kAXxVYs">class methods</a>, <a href="/facts/Class_variable/H5b1PUyR">class variables</a>) should match the business domain. For example: if software processes loan applications, it might have classes like "loan application", "customers", and methods such as "accept offer" and "withdraw".
Domain-driven design is predicated on the following goals:

<ul><li>placing the project's primary focus on the core <a href="/facts/Domain_(software_engineering)/NRnAyFlR">domain</a> and domain logic layer;</li>
<li>basing complex designs on a model of the domain;</li>
<li>initiating a creative collaboration between technical and <a href="/facts/Domain_expert/3kx3sVID">domain experts</a> to iteratively refine a conceptual model that addresses particular domain problems.</li></ul>
Critics of domain-driven design argue that developers must typically implement a great deal of isolation and encapsulation to maintain the model as a pure and helpful construct. While domain-driven design provides benefits such as maintainability, Microsoft recommends it only for complex domains where the model provides clear benefits in formulating a common understanding of the domain.
The term was coined by Eric Evans in his book of the same name published in 2003.

Domain-driven design open-in-new

Domain-driven design