我相信下面的pdf会给你更大的图景。Eric Evans的领域驱动设计

注意:想一个你可以从事的项目，应用你了解的小事情，并看到最佳实践。它还将帮助您提高微服务架构设计方法的能力。

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

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.

从这里被剔除

在TDD和BDD中，你/团队最关注的是系统的测试和行为，而不是代码实现。

类似地，当系统分析师、产品负责人、开发团队，当然还有代码实体/类、变量、函数、用户界面流程使用相同的语言进行交流时，它被称为领域驱动设计

DDD是一个思维过程。在软件设计建模时，您需要将业务领域/流程置于关注的中心，而不是数据结构、数据流、技术、内部和外部依赖关系。

使用DDD建模系统的方法有很多

事件来源(使用事件作为唯一的真相来源) 关系数据库 图形数据库 使用函数式语言

域对象:

用非常朴素的话来说，一个物体

名称是否基于业务流程/流 完全控制其内部状态，即公开方法来操作状态。 始终在使用上下文中满足所有业务不变量/业务规则。 遵循单一责任原则

领域驱动设计是一种用于复杂系统开发的方法和过程，其重点是将问题领域内的活动、任务、事件和数据映射到解决方案领域的技术构件。

领域驱动设计的重点是理解问题领域，以便创建问题领域的抽象模型，然后可以在特定的技术集中实现。领域驱动设计作为一种方法，为模型开发和技术开发如何产生一个系统提供了指导方针，该系统既能满足使用它的人的需求，又能在面对问题领域的变化时保持健壮。

领域驱动设计的过程方面涉及领域专家(了解问题领域的人)和设计/架构专家(了解解决方案领域的人)之间的协作。其思想是拥有一个具有共享语言的共享模型，这样当来自这两个不同领域、有着不同视角的人们讨论解决方案时，他们实际上是在讨论一个具有共享概念的共享知识库。

需要特定系统的人与设计和实现系统的人之间缺乏共同的问题域理解，这似乎是项目成功的核心障碍。领域驱动设计是一种解决这个障碍的方法。

它不仅仅是拥有一个对象模型。重点在于共享沟通和改进协作，以便发现问题领域内的实际需求，并创建适当的解决方案来满足这些需求。

领域驱动的设计:好的和有挑战性的提供了一个简短的概述，评论如下:

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.

另请参阅这篇文章“服务体系结构的领域驱动设计”，其中提供了一个简短的示例。本文提供了以下领域驱动设计的缩略图描述。

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写了很多文章，其中提到了领域驱动设计作为一种方法论。例如，本文BoundedContext概述了来自领域驱动开发的有界上下文概念。

在年轻的时候，有人建议我们建立一个统一的模型 整个业务，但DDD认识到，我们已经学会了“总的 对于一个大型系统来说，统一的领域模型是不可能的 可行的，划算的所以DDD将一大笔 系统转换为有界上下文，每个上下文可以有一个统一的模型- 本质上是一种构造多标准模型的方法。

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

我相信下面的pdf会给你更大的图景。Eric Evans的领域驱动设计

注意:想一个你可以从事的项目，应用你了解的小事情，并看到最佳实践。它还将帮助您提高微服务架构设计方法的能力。