使用微服务意味着从松散耦合服务创建应用程序。该应用程序由几个小型服务组成，每个服务代表一个单独的业务目标。它们可以在复杂的应用中结合后单独开发和轻松维护。

微服务是一种架构设计模型**，具有特定的边界上下文、配置和依赖性。**这些结果来自域驱动设计和 DevOps 的架构原理。域驱动设计是通过代码解决组织问题的想法。

业务目标对业务用户非常重要，具有清晰的界面和功能。这样，微服务可以独立于其他微服务运行。此外，团队还可以独立工作，这实际上是微服务架构的要点。

许多开发人员声称微服务使它们更加高效。这是由于能够在小团队中工作。这允许他们开发不同的小部件，稍后将合并为大型应用程序。

他们花更少的时间与其他开发人员协调，并花更多的时间开发实际代码。最终，这将为最终用户创造更多的价值。

复杂性挑战

复杂性是一个相对的术语。对一个人来说，复杂的东西对另一个人来说很简单。然而，复杂性是域驱动设计应该解决的问题。在此背景下，复杂性意味着互联、许多不同的数据源、不同的业务目标等。

域驱动的方法是解决软件开发的复杂性。另一方面，当挑战简单时，您可以使用紧急设计。但是，当应用程序复杂时，复杂性只会增加，您的问题也会增加。

**业务域的域驱动设计基础。**现代商业环境非常复杂，错误的举动可能导致致命的后果。域驱动设计解决了复杂的域模式，连接到核心业务概念。

Eric Evans 在 2004 年在他的著作《_域驱动设计：解决软件核心的复杂性》中_介绍了这一概念。根据这本书，它侧重于三个原则：

• 该项目的主要重点是核心域和域逻辑。
• 复杂的设计基于域的模型。
• 技术和领域专家之间的协作对于创建解决特定域问题的应用模型至关重要。

域驱动设计中的重要术语

在 DDD 中，请注意以下术语非常重要：

域逻辑

域逻辑是您的建模目的。最常见的情况是，它被称为**商业逻辑。**这是您的业务规则定义数据创建、存储和修改方式的地方。

域模型

域模型包括围绕您试图解决的问题的想法、知识、数据、指标和目标。它包含所有规则和模式，这将有助于您处理复杂的业务逻辑。此外，它们对于满足您业务的要求也很有用。

苏多曼

域由几个子域组成，这些子域条指的是业务逻辑的不同部分。例如，在线零售商店可以将产品目录、库存和交付作为其子域。

设计模式

设计模式是所有关于重复使用的代码。无论您遇到的问题多么复杂，一直在执行对象导向编程的人可能已经创建了一个模式来帮助您解决它。将您的问题分解为初始元素将引导您找到解决方案。通过模式学到的一切，您以后都可以使用您开始编程的任何面向对象的语言。

绑定上下文

绑定上下文是域驱动设计中的一个中心模式，包含应用程序的复杂性。它处理大型模型和团队。这是您在定义域和子域后实现代码的地方。

边界上下文实际上表示**定义和适用特定子域的边界。**在这里，特定的子域是有道理的，而其他人没有。一个实体可以在不同的上下文中具有不同的名称。当边界上下文中的子域发生变化时，整个系统也不必更改。这就是为什么开发人员在上下文之间使用适配器的原因。

无处不在的语言

无处不在的语言是一种方法，指**相同的语言域专家和开发人员使用时，他们谈论他们正在工作的域。**这是必要的，因为项目可能面临语言中断的严重问题。这是因为域专家使用他们自己的行话。同时，技术专业人员使用他们自己的术语来谈论这个领域。

日常讨论中使用的术语与代码中使用的术语之间存在差距。这就是为什么有必要定义每个人使用的一组术语。无处不在的语言中的所有术语都围绕域模型进行结构化。

实体

实体是数据和行为的组合，如用户或产品。它们具有身份，但表示具有行为的数据点。

值对象和聚合

价值对象具有属性，但不能自行存在。例如，航运地址可以是一个值对象。大型和复杂的系统具有无数的实体和价值对象。这就是为什么域模型需要某种结构。这将使它们成为逻辑组，更容易管理。这些组称为**聚合。它们表示相互关联的对象集合，目标是将它们视为单位。此外，它们也有一个聚合根。**这是聚合之外的任何对象可以引用的唯一实体。

域服务

域服务是一个额外的层，也包含域逻辑。它是域模型的一部分，就像实体和值对象一样。同时，应用程序服务是另一个不包含业务逻辑的层。但是，它在这里协调放置在域模型上方的应用程序的活动。

存储 库

存储库模式是简化数据基础结构的业务实体的集合。它从基础设施问题中释放域模型。分层概念强制将关注点分开。

域驱动设计示例

域驱动设计示例

例如，如果我们使用电子商务应用程序，业务域名将是处理订单。当客户想要下订单时，他们首先需要浏览产品。然后，他们选择他们想要的，确认订单，选择运输类型，并支付。然后，应用程序处理客户端提供的数据。

因此，用户应用将包括以下层：

用户界面

在这里，客户可以找到下订单所需的所有信息。在电子商务案例中，这就是产品所在的位置。此层向客户端提供信息并解释其操作。

应用层

此层不包含业务逻辑。这是引导用户从一个到另一个UI屏幕的部分。它还与其他系统的应用层进行交互。它可以执行简单的验证，但它不包含与域相关的逻辑或数据访问。其目的是组织和委派域对象来完成其工作。此外，它是唯一可以访问其他边界上下文的层。

域层

这就是业务领域的概念所在。此层具有有关业务案例和业务规则的所有信息。实体就在这里。 正如我们前面提到的，实体是数据和行为的组合，如用户或产品。

他们具有通过唯一密钥保证的独特身份，即使在属性发生变化时仍保留。例如，在电子商务商店中，每个订单都有一个唯一的标识符。它必须经历几个行动，如确认和航运被视为一个实体。

另一方面，值对象没有唯一的标识符。它们表示各个实体可以共享的属性。例如，这可能是不同客户的相同姓氏。

此部分还包含具有定义操作行为的服务，这些服务不必是任何域的一部分。但是，它们仍然是业务领域的一部分。这些服务是根据无处不在的语言命名的。他们不应该剥夺实体和价值对象的明确责任和行动。客户应能够使用任何给定服务实例。该实例在应用程序寿命期间的历史应该不成问题。

最重要的是，域层处于业务应用的中心。这意味着它应该从其他层中分离出来。它不应该依赖于其他层或其框架。

基础设施层

此层支持其他层之间的通信，并且可以包含 UI 层的支撑库。

域驱动设计的优势

• **更简单的沟通。**由于无处不在的语言，开发人员和团队之间的沟通变得更加容易。由于无处不在的语言可能包含开发人员所指的更简单的术语，因此无需复杂的技术术语。
• **更大的灵活性。**由于 DDD 面向对象，域的一切都基于该域，对象是模块化和笼式的。因此，整个系统可以定期修改和改进。
• **域比 UI/UX 更重要。**由于域是中心概念，开发人员将构建适合特定域的应用程序。这不会是另一个以界面为中心的应用程序。虽然您不应该遗漏 UX，但使用 DDD 方法意味着产品的目标完全针对直接连接到域的用户。

域驱动设计的缺点

• **需要深入的域知识。**即使是技术最先进的开发团队，团队中也必须至少有一名领域专家了解作为应用中心的学科领域的精确特征。有时需要几个完全了解域的团队成员加入开发团队。
• **包含重复的做法。**虽然许多人会说这是一个优势，但域驱动的设计包含许多重复的做法。DDD 鼓励使用连续集成来构建强大的应用程序，以便在必要时能够自我调整。许多组织在这些方法上可能有困难。更具体地，如果他们以前的经验通常与不太灵活的增长模式有关，比如瀑布模型。
• **它可能不适合高技术项目。**域驱动设计非常适合具有复杂业务逻辑的应用程序。但是，对于域分复杂性小但技术复杂性高的应用程序，它可能不是最佳解决方案。对于面向业务的领域专家来说，具有极高技术复杂性的应用可能非常具有挑战性。这可能会导致许多限制，而对于所有团队成员来说，这些限制可能无法解决。

结论

域驱动设计是解决特定域模型的软件工程方法。解决方案通过将执行与关键业务原则连接起来围绕业务模式展开。

域专家和开发团队之间的常见术语包括域逻辑、子域、边界上下文、上下文图、域模型和无处不在的语言，作为协作和改进应用模型以及解决任何域相关挑战的一种方式。

通过本文，我们希望定义域驱动设计的核心概念。此外，我们想解释它们，增加方法的优点和缺点。这样，我们希望帮助您确定这是否适合您的业务和应用程序。

微服务比传统架构具有一些重大优势，提供可扩展性、可访问性和灵活性。此外，这种方法使开发人员保持专注，因为每个微服务都是一个松散耦合的服务，只有一个问责理念。