只有理解了以下内容，你才能理解领域驱动设计:

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.

从这里被剔除

我不想重复别人的答案，所以，简而言之，我解释一些常见的误解

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.

使组织对问题领域有广泛的理解 为每个子问题领域开发一种普遍存在的语言(一种共同的思维模式)。 在解决方案域(代码)中尽可能使用该语言。 只有选择技术。 不要被技术驱动，而是被问题领域或业务驱动。

DDD(领域驱动设计)是一个用于分析项目需求和处理这些需求复杂性的有用概念。在此之前，人们通过考虑类和表之间的关系来分析这些需求，事实上他们的设计是基于数据库表关系的，它并不老，但它有一些问题:

在需求复杂的大项目中，这种方法并不有用，尽管这是一种设计小项目的好方法。 当你与没有技术概念的非技术人员打交道时，这种冲突可能会给我们的项目带来一些巨大的问题。

因此，DDD处理第一个问题时，将主项目视为一个域，并将项目的每个部分分割成小块，我们称之为有界上下文(Bounded Context)，其中每个部分对其他部分没有任何影响。 第二个问题已经通过一种通用语言解决了，这种语言是技术团队成员和产品负责人之间的通用语言，产品负责人不是技术人员，但对自己的需求有足够的了解

一般来说，域的简单定义是为所有者和其他团队赚钱的主要项目。

这是另一篇关于领域驱动设计的好文章。如果你申请的不是大学作业。基本前提是围绕实体构建所有内容，并拥有强大的领域模型。区分提供基础设施相关服务(如发送电子邮件、持久化数据)和实际处理核心业务需求的服务。

希望这能有所帮助。

只有理解了以下内容，你才能理解领域驱动设计:

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.

从这里被剔除