什么是领域驱动设计？
有人可以（用简洁的术语）解释一下领域驱动设计到底是什么吗？我经常看到这个术语，但真的不明白它是什么或它是什么样子。它与非领域驱动设计有何不同？
另外，有人可以解释什么是领域对象吗？域与普通对象有何不同？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
编辑：
由于这似乎是 Google 上的最佳结果，而我下面的答案不是，请参考这个更好的答案：
https:/ /stackoverflow.com/a/1222488/1240557
旧答案（不太完整:)）
来自：Eric Evans 的领域驱动设计。
这本书很好地描述了 DDD。
注册以下载本书的摘要。
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 :))
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.
领域驱动设计是一种用于开发复杂系统的方法和流程规定，其重点是将问题域中的活动、任务、事件和数据映射到解决方案域的技术工件。
领域驱动设计的重点是理解问题域，以便创建问题域的抽象模型，然后可以在一组特定的技术中实现该模型。领域驱动设计作为一种方法论，为模型开发和技术开发如何产生一个既能满足使用人员的需求，又能在面对问题领域的变化时保持稳健的系统提供了指导。
领域驱动设计的流程方面涉及领域专家（了解问题领域的人员）和设计/架构专家（了解解决方案领域的人员）之间的协作。这个想法是建立一个具有共享语言的共享模型，以便当来自这两个不同领域的人们以两种不同的视角讨论解决方案时，他们实际上是在讨论具有共享概念的共享知识库。
需要特定系统的人员与设计和实施该系统的人员之间缺乏共同的问题领域理解似乎是项目成功的核心障碍。领域驱动设计是解决这一障碍的一种方法。
它不仅仅是拥有一个对象模型。重点实际上是共享沟通和改进协作，以便可以发现问题领域内的实际需求，并创建适当的解决方案来满足这些需求。
领域驱动设计：好的和具有挑战性的通过以下评论提供了简要概述：
另请参阅这篇文章服务架构的领域驱动设计，其中提供了一个简短的例子。本文提供了领域驱动设计的以下缩略图描述。
Martin Fowler 撰写了许多文章，其中提到了领域驱动设计作为一种方法。例如，本文 BoundedContext 概述了领域驱动开发中的有界上下文概念。
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:
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.
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.
您只能通过首先理解以下内容来理解领域驱动设计：
摘自此处
You CAN ONLY understand Domain driven design by first comprehending what the following are:
Culled from here
这是另一篇关于领域驱动设计的好文章。如果您的申请比大学作业更严肃。基本前提是围绕实体构建一切并拥有强大的领域模型。区分提供与基础设施相关的服务（例如发送电子邮件、持久数据）的服务和实际执行核心业务需求的服务。
希望有帮助。
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.
正如在 TDD 和 TDD 中一样。 BDD 您/团队最关注的是系统的测试和行为，而不是代码实现。
类似地，当系统分析师、产品负责人、开发团队，当然还有代码（实体/类、变量、函数、用户界面流程）使用相同的语言进行通信时，其称为领域驱动设计
DDD 是一个思维过程。在对软件设计进行建模时，您需要将业务领域/流程放在关注的中心，而不是数据结构、数据流、技术、内部和外部依赖性。
有很多方法可以使用 DDD
来建模系统。领域对象：
对象
As in TDD & 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
Domain object:
In very naive words, an object which
DDD（领域驱动设计）是一个有用的概念，用于分析项目的需求并处理这些需求的复杂性。在此之前，人们通过考虑类和表之间的关系来分析这些需求，实际上他们的设计是基于数据库表的它并不古老，但有一些问题：
在具有复杂需求的大型项目中，它没有用，尽管这是小型项目的一种很好的设计方式。
当你与非技术人员打交道时，他们没有技术概念，这种冲突可能会给我们的项目带来一些巨大的问题。
因此，DDD 处理第一个问题时，将主项目视为一个域，并将该项目的每个部分分割成我们著名的限界上下文的小块，并且每个块对其他块没有任何影响。
第二个问题已经通过通用语言解决了，这是技术团队成员和产品所有者之间的通用语言，这些产品所有者不是技术人员，但对他们的需求有足够的了解。
通常，域的简单定义是主要的为业主和其他团队赚钱的项目。
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.
我不想重复别人的答案，所以，简而言之，我解释一些常见的误解
您应该避免在整个项目中使用它
<块引用>
DDD 强调需要将大部分精力集中在核心子域上。核心子域是
产品的成功与失败的区别。它是
产品的独特卖点，也是制造而不是购买的原因。
基本上是因为花费了太多的时间和精力。因此，建议将整个域分解为子域，并将其应用于具有高商业价值的子域。 （例如不在电子邮件等通用子域中，...）
它不是面向对象的编程。它主要是解决问题的方法并且（有时）你不需要使用OO模式（例如四人帮）在您的领域模型中。仅仅是因为业务专家无法理解它（他们对工厂、装饰器不太了解……）。 DDD 中甚至有一些模式（例如事务脚本、表模块）并不是 100% 符合 OO 概念。
I do not want to repeat others' answers, so, in short I explain some common misunderstanding
You should avoid using it all across your project
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.
我相信下面的 pdf 将为您提供更全面的了解。 Eric Evans 的领域驱动设计
注意：想想一个您可以从事的项目，应用您所理解的小事情并查看最佳实践。它还将帮助您提高微服务架构设计方法的能力。
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.
通过以下方式获得组织对问题领域的广泛理解
为每个子问题域开发一种通用语言（通用心理模型）。
在解决方案域（代码）中尽可能接近地使用该语言。
然后才选择技术。
不要受技术驱动，而要受问题领域或业务驱动。
Get an organization wide understanding of the problem domain by
developing a ubiquitous language (a common mental model) per sub-problem-domain.
Use that language as close as possible in solution domains (code).
Only then choose technologies.
Don't be technology driven but problem domain or business driven.