What is Domain Driven Design

Question

Can somebody please explain  in succinct terms  what exactly is domain driven design  I see the term quite a lot but really don t understand what it is or what it looks like  How does it differ from non-domain driven design   Also  can somebody explain what a Domain Object is  How does domain differ from normal objects

User · Accepted Answer

EDIT   As this seem to be a top result on Google and my answer below is not  please refer to this much better answer   https   stackoverflow com a 1222488 1240557  OLD ANSWER  not so complete         In order to create good software  you have to know what that software   is all about  You cannot create a banking software system unless you   have a good understanding of what banking is all about  one must   understand the domain of banking    From  Domain Driven Design by Eric Evans   This book does a pretty good job of describing DDD   Register to download a summary of the book  or download the summary directly

User · Answer

I believe the following pdf will give you the bigger picture  Domain Driven Design by Eric Evans  NOTE  Think of a project you can work on  apply the little things you understood and see best practices  It will help you to grow your ability to the micro service architecture design approach too

User · Answer

You CAN ONLY understand Domain driven design by first comprehending what the following are      What is a domain       The field for which a system is built  Airport management  insurance sales  coffee shops  orbital flight  you name it       It s not unusual for an application to span several different domains  For example  an online retail system might be working in the domains of shipping  picking appropriate ways to deliver  depending on items and destination   pricing  including promotions and user-specific pricing by  say  location   and recommendations  calculating related products by purchase history        What is a model        A useful approximation to the problem at hand   -- Gerry Sussman      An Employee class is not a real employee  It models a real employee  We know that the model does not capture everything about real employees  and that s not the point of it  It s only meant to capture what we are interested in for the current context       Different domains may be interested in different ways to model the same thing  For example  the salary department and the human resources department may model employees in different ways       What is a domain model       A model for a domain       What is Domain-Driven Design  DDD        It is a development approach that deeply values the domain model and connects it to the implementation  DDD was coined and initially developed by Eric Evans    Culled from here

User · Answer

Here is another good article that you may check out on Domain Driven Design  if your application is anything serious than college assignment  The basic premise is structure everything around your entities and have a strong domain model  Differentiate between services that provide infrastructure related things  like sending email  persisting data  and services that actually do things that are your core business requirments   Hope that helps

User · Answer

Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities  tasks  events  and data within a problem domain into the technology artifacts of a solution domain   The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies  Domain Driven Design as a methodology provides guidelines for how this model development and technology development can result in a system that meets the needs of the people using it while also being robust in the face of change in the problem domain   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   The lack of a shared problem domain understanding between the people who need a particular system and the people who are designing and implementing the system seems to be a core impediment to successful projects  Domain Driven Design is a methodology to address this impediment   It is more than having an object model  The focus is really about the shared communication and improving collaboration so that the actual needs within the problem domain can be discovered and an appropriate solution created to meet those needs   Domain-Driven Design  The Good and The Challenging provides a brief overview with this comment      DDD helps discover the top-level architecture and inform about the   mechanics and dynamics of the domain that the software needs to   replicate  Concretely  it means that a well done DDD analysis   minimizes misunderstandings between domain experts and software   architects  and it reduces the subsequent number of expensive requests   for change  By splitting the domain complexity in smaller contexts    DDD avoids forcing project architects to design a bloated object   model  which is where a lot of time is lost in working out   implementation details     in part because the number of entities to   deal with often grows beyond the size of conference-room white boards    Also see this article Domain Driven Design for Services Architecture which provides a short example  The article provides the following thumbnail description of Domain Driven Design      Domain Driven Design advocates modeling based on the reality of   business as relevant to our use cases  As it is now getting older and   hype level decreasing  many of us forget that the DDD approach really   helps in understanding the problem at hand and design software towards   the common understanding of the solution  When building applications    DDD talks about problems as domains and subdomains  It describes   independent steps areas of problems as bounded contexts  emphasizes a   common language to talk about these problems  and adds many technical   concepts  like entities  value objects and aggregate root rules to   support the implementation    Martin Fowler has written a number of articles in which Domain Driven Design as a methodology is mentioned  For instance this article  BoundedContext  provides an overview of the bounded context concept from Domain Driven Development      In those younger days we were advised to build a unified model of the   entire business  but DDD recognizes that we ve learned that  total   unification of the domain model for a large system will not be   feasible or cost-effective  1  So instead DDD divides up a large   system into Bounded Contexts  each of which can have a unified model -   essentially a way of structuring MultipleCanonicalModels

User · Answer

As in TDD  amp  BDD you  team focus the most on test and behavior of the system than code implementation  Similar way when system analyst  product owner  development team  and ofcourse the code - entities  classes  variables  functions  user interfaces processes communicate using the same language  its called Domain Driven Design DDD is a thought process  When modeling a design of software you need to keep business domain process in the center of attention rather than data structures  data flows  technology  internal and external dependencies  There are many approaches to model systerm using DDD  event sourcing  using events as a single source of truth  relational databases graph databases using functional languages  Domain object  In very naive words  an object which  has name based on business process flow has complete control on its internal state i e exposes methods to manipulate state  always fulfill all business invariants business rules in context of its use  follows single responsibility principle

User · Answer

I do not want to repeat others  answers  so  in short I explain some common misunderstanding   Practical resource  PATTERNS  PRINCIPLES  AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett It is a methodology for complicated business systems  It takes all the technical matters out when communicating with business experts It provides an extensive understanding of  simplified and distilled model of  business across the whole dev team  it keeps business model in sync with code model by using ubiquitous language  the language understood by the whole dev team  business experts  business analysts        which is used for communication within the dev team or dev with other teams It has nothing to do with Project Management  Although it can be perfectly used in project management methods like Agile  You should avoid using it all across your project     DDD stresses the need to focus the most effort on the core subdomain  The core subdomain is the   area of your product that will be the difference between it being a success and it being a failure  It   s   the product   s unique selling point  the reason it is being built rather than bought    Basically  it is because it takes too much time and effort  So  it is suggested to break down the whole domain into subdomain and just apply it in those with high business value   ex not in generic subdomain like email       It is not object oriented programming  It is mostly problem solving approach and  sometimes  you do not need to use OO patterns  such as Gang of Four  in your domain models  Simply because it can not be understood by Business Experts  they do not know much about Factory  Decorator        There are even some patterns in DDD  such as The Transaction Script  Table Module  which are not 100  in line with OO concepts

User · Answer

DDD domain driven design  is a useful concept for analyse of requirements of a project and handling the complexity of these requirements Before that people were analysing these requirements with considering the relationships between classes and tables and in fact their design were based on database tables relationships it is not old but it has some problems     In big projects with complex requirements it is not useful although this is a great way of design for small projects  when you are dealing with none technical persons that they don t have technical concept  this conflict may cause some huge problems in our project    So DDD handle the first problem with considering the main project as a Domain and splitting each part of this project to small pieces which we are famous to Bounded Context and each of them do not have any influence on other pieces  And the second problem has been solved with a ubiquitous language which is a common language between technical team members and Product owners which are not technical but have enough knowledge about their requirements   Generally the simple definition for Domain is the main project that makes money for the owners and other teams

[domain-driven-design] What is Domain Driven Design?

Examples related to domain-driven-design