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

EDIT:

As this seem to be a top result on 10 Google and my answer below is not, please 9 refer to this much better answer:

https://stackoverflow.com/a/1222488/1240557

OLD ANSWER 8 (not so complete :))

In order to create good 7 software, you have to know what that software is 6 all about. You cannot create a banking software 5 system unless you have a good understanding 4 of what banking is all about, one must understand 3 the domain of banking.

From: Domain Driven 2 Design by Eric Evans.

This book does a pretty 1 good job of describing DDD.

Register to download a summary of the book, or download the summary directly.

Domain Driven Design is a methodology and 84 process prescription for the development 83 of complex systems whose focus is mapping 82 activities, tasks, events, and data within 81 a problem domain into the technology artifacts 80 of a solution domain.

The emphasis of Domain 79 Driven Design is to understand the problem 78 domain in order to create an abstract model 77 of the problem domain which can then be 76 implemented in a particular set of technologies. Domain 75 Driven Design as a methodology provides 74 guidelines for how this model development 73 and technology development can result in 72 a system that meets the needs of the people 71 using it while also being robust in the 70 face of change in the problem domain.

The 69 process side of Domain Driven Design involves 68 the collaboration between domain experts, people 67 who know the problem domain, and the design/architecture 66 experts, people who know the solution domain. The 65 idea is to have a shared model with shared 64 language so that as people from these two 63 different domains with their two different 62 perspectives discuss the solution they are 61 actually discussing a shared knowledge base 60 with shared concepts.

The lack of a shared 59 problem domain understanding between the 58 people who need a particular system and 57 the people who are designing and implementing 56 the system seems to be a core impediment 55 to successful projects. Domain Driven Design 54 is a methodology to address this impediment.

It 53 is more than having an object model. The 52 focus is really about the shared communication 51 and improving collaboration so that the 50 actual needs within the problem domain can 49 be discovered and an appropriate solution 48 created to meet those needs.

Domain-Driven Design: The Good and The Challenging provides a 47 brief overview with this comment:

DDD helps 46 discover the top-level architecture and 45 inform about the mechanics and dynamics 44 of the domain that the software needs to replicate. Concretely, it 43 means that a well done DDD analysis minimizes 42 misunderstandings between domain experts 41 and software architects, and it reduces 40 the subsequent number of expensive requests for 39 change. By splitting the domain complexity 38 in smaller contexts, DDD avoids forcing 37 project architects to design a bloated object model, which 36 is where a lot of time is lost in working 35 out implementation details — in part because 34 the number of entities to deal with often 33 grows beyond the size of conference-room 32 white boards.

Also see this article Domain Driven Design for Services Architecture which 31 provides a short example. The article provides 30 the following thumbnail description of Domain 29 Driven Design.

Domain Driven Design advocates 28 modeling based on the reality of business 27 as relevant to our use cases. As it is now 26 getting older and hype level decreasing, many 25 of us forget that the DDD approach really helps 24 in understanding the problem at hand and 23 design software towards the common understanding 22 of the solution. When building applications, DDD 21 talks about problems as domains and subdomains. It 20 describes independent steps/areas of problems 19 as bounded contexts, emphasizes a common 18 language to talk about these problems, and 17 adds many technical concepts, like entities, value 16 objects and aggregate root rules to support 15 the implementation.

Martin Fowler has written 14 a number of articles in which Domain Driven 13 Design as a methodology is mentioned. For 12 instance this article, BoundedContext, provides an overview 11 of the bounded context concept from Domain 10 Driven Development.

In those younger days 9 we were advised to build a unified model 8 of the entire business, but DDD recognizes 7 that we've learned that "total unification 6 of the domain model for a large system will 5 not be feasible or cost-effective" 1. So 4 instead DDD divides up a large system 3 into Bounded Contexts, each of which can 2 have a unified model - essentially a way 1 of structuring MultipleCanonicalModels.

You CAN ONLY understand Domain driven design by 28 first comprehending what the following are:

What is a domain?

The 27 field for which a system is built. Airport 26 management, insurance sales, coffee shops, orbital 25 flight, you name it.

It's not unusual for 24 an application to span several different 23 domains. For example, an online retail system 22 might be working in the domains of shipping 21 (picking appropriate ways to deliver, depending 20 on items and destination), pricing (including 19 promotions and user-specific pricing by, say, location), and 18 recommendations (calculating related products 17 by purchase history).

What is a model?

"A useful approximation 16 to the problem at hand." -- Gerry Sussman

An 15 Employee class is not a real employee. It 14 models a real employee. We know that the 13 model does not capture everything about 12 real employees, and that's not the point 11 of it. It's only meant to capture what we 10 are interested in for the current context.

Different 9 domains may be interested in different ways 8 to model the same thing. For example, the 7 salary department and the human resources 6 department may model employees in different 5 ways.

What is a domain model?

A model for a domain.

What is Domain-Driven Design (DDD)?

It is a development 4 approach that deeply values the domain model 3 and connects it to the implementation. DDD 2 was coined and initially developed by Eric 1 Evans.

Culled from here

Here is another good article that you may 9 check out on Domain Driven Design. if your application is anything 8 serious than college assignment. The basic 7 premise is structure everything around your 6 entities and have a strong domain model. Differentiate 5 between services that provide infrastructure 4 related things (like sending email, persisting 3 data) and services that actually do things 2 that are your core business requirments.

Hope 1 that helps.

As in TDD & BDD you/ team focus the 13 most on test and behavior of the system 12 than code implementation.

Similar way when 11 system analyst, product owner, development 10 team and ofcourse the code - entities/ classes, variables, functions, user 9 interfaces processes communicate using the 8 same language, its called Domain Driven 7 Design

DDD is a thought process. When modeling 6 a design of software you need to keep business 5 domain/process in the center of attention 4 rather than data structures, data flows, technology, internal 3 and external dependencies.

There are many 2 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 1 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

DDD(domain driven design) is a useful concept 27 for analyse of requirements of a project 26 and handling the complexity of these requirements.Before 25 that people were analysing these requirements 24 with considering the relationships between 23 classes and tables and in fact their design 22 were based on database tables relationships 21 it is not old but it has some problems:

• In 20 big projects with complex requirements it 19 is not useful although this is a great way 18 of design for small projects.

• when you are 17 dealing with none technical persons that 16 they don,t have technical concept, this 15 conflict may cause some huge problems in 14 our project.

So DDD handle the first problem 13 with considering the main project as a Domain 12 and splitting each part of this project 11 to small pieces which we are famous to Bounded 10 Context and each of them do not have any 9 influence on other pieces. And the second 8 problem has been solved with a ubiquitous 7 language which is a common language between 6 technical team members and Product owners 5 which are not technical but have enough 4 knowledge about their requirements

Generally 3 the simple definition for Domain is the main project 2 that makes money for the owners and other 1 teams.

I do not want to repeat others' answers, so, in 21 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 20 stresses the need to focus the most effort 19 on the core subdomain. The core subdomain 18 is the area of your product that will 17 be the difference between it being a success 16 and it being a failure. It’s the product’s 15 unique selling point, the reason it is being 14 built rather than bought.

  Basically, it is 13 because it takes too much time and effort. So, it 12 is suggested to break down the whole domain 11 into subdomain and just apply it in those 10 with high business value. (ex not in generic 9 subdomain like email, ...)

• It is not object oriented programming. It is mostly 8 problem solving approach and (sometimes) you do not 7 need to use OO patterns (such as Gang of 6 Four) in your domain models. Simply because 5 it can not be understood by Business Experts 4 (they do not know much about Factory, Decorator, ...). There 3 are even some patterns in DDD (such as The 2 Transaction Script, Table Module) which 1 are not 100% in line with OO concepts.

I believe the following pdf will give you 6 the bigger picture. Domain Driven Design by Eric Evans

NOTE: Think of a project 5 you can work on, apply the little things 4 you understood and see best practices. It 3 will help you to grow your ability to the 2 micro service architecture design approach 1 too.

Get an organization wide understanding of 6 the problem domain by developing a ubiquitous 5 language (a common mental model) per sub-problem-domain. Use 4 that language as close as possible in solution 3 domains (code). Only then choose technologies. Don't 2 be technology driven but problem domain 1 or business driven.