迁移学习简而言之_简而言之，领域驱动设计-CSDN博客

迁移学习简而言之

Domain-Driven Design, that’s what you use when you’re building Microservices. It’s a technique that can be used to cut monoliths into small bits, and it’s about Aggregates and Event-Sourcing. Or is it?

域驱动设计，即构建微服务时所使用的域。这是一种可用于将整料切成小块的技术，它与聚合和事件源有关。还是？

The book Domain-Driven Design by Eric Evans first appeared in 2004. It’s a book about communication, language, context, and models. And it’s a book about object-oriented programming and design patterns.

埃里克·埃文斯(Eric Evans)的著作《域驱动设计》(Domain-Driven Design)于2004年首次问世。这是一本有关面向对象的编程和设计模式的书。

In essence, Domain-Driven Design is about creating a solution that reflects the problem at hand. It’s about designing software together. Not just the development team, but both the development-team and domain-experts.

本质上，域驱动设计是指创建一种解决方案，以反映当前的问题。这是关于一起设计软件。不只是开发团队，而且包括开发团队和领域专家。

Domain-Driven Design is about common understanding.

域驱动设计是关于共识的。

无所不在的语言 (The ubiquitous language)

Assumptions are the mother of all screw-ups. You ask for a feature, the team thinks they understand, and they end up building something different.

假设是所有问题的根源。您要求一个功能，团队认为他们理解了，他们最终会建立一些不同的东西。

Consider storing something in a database, for example. Sounds pretty straight forward… But somebody from the finance department may refer to their Excel-sheet when they say “database”. A developer probably means an instance of a SQL server. It’s the same word, but it has a different meaning.

例如，考虑将某些内容存储在数据库中。听起来很简单……但是财务部门的某些人在说“数据库”时可能会参考他们的Excel工作表。开发人员可能意味着一个SQL Server实例。这是同一个词，但含义不同。

Speaking the same language is the cornerstone of effective teamwork; Having a common understanding, having a language in which words mean the same thing to everybody in the team: A ubiquitous language.

说相同的语言是有效的团队合作的基石。具有共识，拥有一种语言，其中的单词对团队中的每个人都具有相同的含义：一种无处不在的语言。

Complex things are hard to comprehend if they’re not visualized. Doodles on a whiteboard are hard to convert to code. Alberto Brandolini invented a technique to solve that problem: A mapping-technique called Event-Storming, to collaboratively create a common understanding of a process.

如果不可视化，则很难理解复杂的事物。 白板上的涂鸦很难转换为代码。 Alberto Brandolini发明了一种解决该问题的技术：一种称为“事件存储”的制图技术，以协作方式创建对过程的共识。

The ubiquitous language has a purpose. The words of the ubiquitous language are the names of the objects in the code. To be more specific: They’re the names of the domain-models. That makes communication between the development team and the domain-experts more effective.

无处不在的语言是有目的的。通用语言的单词是代码中对象的名称。更具体地说：它们是域模型的名称。这使得开发团队与领域专家之间的沟通更加有效。

有界的背景 (Bounded context)

A model is a representation of something in a way that makes sense in a given context. A different context requires a different model. Using the same model for different purposes can work counter-productive.

模型是在给定上下文中有意义的某种事物的表示。不同的上下文需要不同的模型。将相同模型用于不同目的可能会适得其反。

Imagine your business is building and selling houses. A carpenter needs a model to build it, and a marketeer needs another model to sell it:

想象您的企业正在建造和出售房屋。木匠需要一个模型来构建它，而市场商人需要另一个模型来出售它：

The model on the left has lots of technical details the carpenter needs to build it correctly. But they are distracting to a potential buyer. All they care about is what it would look like with the furniture in it. Imagine trying to combine these two models. It’s just not going to work…

左侧的模型具有木匠正确构建它所需的许多技术细节。但它们分散了潜在买家的注意力。他们所关心的只是摆放家具的样子。想象一下试图将这两种模型结合起来。只是行不通...

A business process can be captured in a domain model. Currently and unfortunately, it’s a common practice to create one big model that can be used for every use-case. Domain-Driven Design advertises the opposite: Represent objects differently, depending on the context in which it is used.

可以在域模型中捕获业务流程。当前和不幸的是，创建一个可以用于每个用例的大模型是一种常见的做法。域驱动设计则相反：取决于对象使用的上下文，以不同的方式表示对象。

Bounded Contexts are the contexts that apply in the business. “Customer” means something different from a customer-relationship-management-perspective, then from a shipping-perspective. Each bounded context needs its own domain-model and is usually maintained by one team.

有界上下文是在业务中应用的上下文。 “客户”是指不同于客户关系管理角度，然后不同于发货角度的东西。每个有界上下文都需要有自己的域模型，并且通常由一个团队维护。

集合，实体和值类型 (Aggregates, entities, and value-types)

The validity of the state of an object depends on the context in which it is used. Every context has different business rules. Using the same model in different contexts makes it impossible to encapsulate the business logic that applies in the domain object. It can only be validated outside of the domain. As a result, the business logic gets scattered and duplicated all over the code-base. The chances of bugs increases and maintaining the code-base becomes more difficult, as a result.

对象状态的有效性取决于使用它的上下文。每个上下文都有不同的业务规则。在不同的上下文中使用相同的模型将不可能封装适用于域对象的业务逻辑。只能在域外进行验证。结果，业务逻辑在整个代码库中变得分散且重复。结果，错误的机会增加，维护代码库变得更加困难。

To have a model for a specific purpose, applied in a single context, has a huge benefit: It allows the developer to code a class that can protect its integrity.

为特定目的的模型在单个上下文中应用具有巨大的好处：它允许开发人员编写一个可以保护其完整性的类。

Instead of having other classes assign values to the domain-model, the domain model can have methods to assign values and to validate the correctness of these values before applying them. As a result, the business logic will be in the domain-model, with a lot less duplication as a result.

代替让其他类为域模型分配值，域模型可以具有在应用它们之前分配值并验证这些值的正确性的方法。结果，业务逻辑将在域模型中，从而减少了很多重复。

Imagine having a taxi-cab domain, with a cab-entity. This is what the code would look like:

想象一下，拥有出租车出租车域，并且具有出租车实体。代码如下所示：

Typically, entities in domain-driven design have public getters, but private setters. The method that sets the value, is a method with a name that makes sense in the context. It protects the business invariants.

通常，域驱动设计中的实体具有公共获取者，但具有私有获取者。设置值的方法是一种名称在上下文中有意义的方法。它保护业务不变式。

Create separate value-objects. Rather than passing primitive data-types to a method. Mistakes are easily made. How will you validate you didn’t mistake the longitude for the latitude?

创建单独的价值对象。而不是将原始数据类型传递给方法。容易犯错误。您将如何验证自己没有把经度误认为纬度？

“Make the incorrect inexpressible”

“使不正确的东西无法表达”

Harden your code-base against mistakes. The Domain-Driven Design book describes a series of programming practices to achieve that:

加强代码库以防止错误。《域驱动设计》一书描述了实现这一目标的一系列编程实践：

Value objects represent the immutable objects in the domain. Like Euro’s, Kilometers for example.
值对象表示域中的不可变对象。像欧元一样，例如公里。
Entities represent things that are mutable. For example a Cab. It has milage, it has a diver, and so forth.
实体代表可变的东西。例如出租车。它有里程，有潜水员，依此类推。
Aggregates are an aggregation of entities and values within a consistency boundary.
集合是一致性边界内的实体和值的集合。

The value-objects, entities, and aggregates are the domain model. Find a complete code-example here.

价值对象，实体和集合是领域模型。在此处找到完整的代码示例。

服务 (Services)

Distilling the domain from the conversations between various people in the company is one thing. But these domain-objects don’t do anything by themselves. The need to be used by something.

从公司中各个人之间的对话中提取域名是一回事。但是这些领域对象本身不会做任何事情。需要被某些东西使用。

A company has objects and processes. Consider a taxi-cab company. These cars don’t drive themselves. There’s a process. A cab driver enters the cab, he gets called by dispatch and they tell him where to pick up the next customer.

公司有对象和流程。考虑一家出租车公司。这些汽车不会自己开车。有一个过程。出租车司机进入出租车，他被派遣呼叫，他们告诉他在哪里接下一位顾客。

Use domain-models in a service. The service describes the business-process by invoking the domain-objects. Like so:

在服务中使用域模型。该服务通过调用域对象来描述业务流程。像这样：

(Review the complete code-example here.)

(在此处 查看完整的代码示例 。)

演化 (Evolution)

The Domain-Driven Design book starts with several chapters about technical patterns. The chapters about the ubiquitous language and the bounded contexts follow. Event Storming isn’t mentioned in the book either.

《域驱动设计》一书以有关技术模式的几章开头。接下来是有关无处不在的语言和有限上下文的章节。书中也没有提到事件风暴。

Alberto Brandolini’s Event Storming had a big impact on Domain-Driven Design. It made it possible to design aggregates, entities, services, and so forth, with domain-experts that don’t know anything about IT.

Alberto Brandolini的事件风暴对领域驱动设计产生了重大影响。借助对IT一无所知的领域专家，可以设计聚合，实体，服务等。

Today’s Domain-Driven Design focusses on communication over coding things in a given way.

当今的域驱动设计专注于通过给定方式对事物进行编码的通信。

Also, note that the Domain-Driven Design book was written in 2004. Cloud did not exist yet, neither did Microservices, Event-Driven-Architecture nor CQRS. Event-Driven Architectures with event handlers and command handlers can easily be used in combination with Domain-Objects. And a lot of people do so.

另外，请注意，《域驱动设计》一书是在2004年编写的。云还不存在，微服务，事件驱动架构和CQRS都不存在。具有事件处理程序和命令处理程序的事件驱动架构可以轻松地与域对象结合使用。很多人都这样做。

摘要 (Summary)

Domain-Driven Design is a book that was written by Eric Evans in 2004. It describes a way to create a rich domain-model by collaboration between business- and IT.

域驱动设计是一本由埃里克·埃文斯(Eric Evans)在2004年写的书。它描述了一种通过业务和IT之间的协作来创建丰富的域模型的方法。

Domain-Driven Design is about designing models. About designing the simplest model that works in one single context. Find the contexts in the domain, and find the correct entities, aggregates, and value-objects as a result of that.

域驱动设计是关于设计模型的。关于设计在单个上下文中工作的最简单模型。在域中找到上下文，并因此找到正确的实体，集合和值对象。

Use several patterns and concepts to make the incorrect inexpressible in your code, making it harder to write buggy code. Name domain-objects like the domain-experts call these objects in real life, to make communication easier.

使用几种模式和概念使错误的代码无法表达，从而使编写错误的代码变得更加困难。像领域专家这样的域名领域对象在现实生活中会调用这些对象，从而使交流更加容易。

Visualize complex things to make it easier to share knowledge about it.

可视化复杂的事物，使共享知识变得更加容易。