使用微服务意味着从松散耦合的服务创建应用程序。该应用程序由几个小服务组成，每个小服务代表一个单独的业务目标。在复杂的应用程序中结合使用之后，它们可以单独开发和维护。
微服务是具有特定有边界的上下文，配置和依赖关系的体系结构设计模型。这些来自领域驱动设计和DevOps的体系结构原理。域驱动设计是通过代码解决组织问题的想法。
具有清晰的界面和功能的业务目标对业务用户而言很重要。这样，微服务可以独立于其他微服务运行。而且，团队还可以独立地进行工作，这实际上是微服务体系结构的重点。
许多开发人员声称微服务使它们更加高效。这是由于能够在小团队中工作。这使他们能够开发不同的小部件，这些小部件随后将被合并为一个大型应用程序。
他们花费更少的时间与其他开发人员进行协调，而将更多的时间用于开发实际的代码。最终，这为最终用户创造了更多价值。
复杂性挑战
复杂性是一个相对术语。一个人的复杂性对另一个人而言简单。但是，复杂性是DDD应解决的问题。在这种情况下，复杂性意味着互连，许多不同的数据源，不同的业务目标等。
DDD方法是在这里解决软件开发的复杂性。另一方面，当挑战很简单时，您可以使用紧急设计。但是，当您的应用程序很复杂时，复杂性只会增加，您的问题也会随之增加。
DDD设计基于业务域：现代商业环境非常复杂，错误的举动可能导致致命的后果。域驱动的设计解决了复杂的域模型，并连接到核心业务概念。
埃里克·埃文斯（Eric Evans）于2004年在他的著作《域驱动设计：解决软件中心的复杂性》中介绍了这一概念。根据这本书，它着重于三个原则：
- 该项目的主要重点是核心领域和领域逻辑。
- 复杂的设计基于领域的模型。
- 技术专家和领域专家之间的协作对于创建可解决特定领域问题的应用程序模型至关重要。
域驱动设计中的重要术语
在DDD中，请注意以下术语，这一点很重要：
1.领域逻辑：领域逻辑是建模的目的。最通常地，它被称为业务逻辑。这是您的业务规则定义数据创建、存储和修改方式的地方。
2.领域模型：领域模型包括围绕您要解决的问题的想法，知识，数据，指标和目标。它包含将帮助您处理复杂业务逻辑的所有规则和模式。而且，它们将对满足您的业务要求很有用。
3.子域：领域由几个子域组成，这些子域引用业务逻辑的不同部分。例如，在线零售商店可以将产品目录，库存和交付作为其子域。
4.设计模式：设计模式都是关于重用代码的。无论您遇到什么复杂的问题，一直在进行面向对象编程的人都可能已经创建了一种模式来帮助您解决它。将您的问题分解为最初的要素将使您找到解决方案。通过模式学习的所有内容，以后都可以用于开始编程的任何面向对象的语言。
5.有界的上下文：有界上下文是域驱动设计中的中心模式，其中包含应用程序的复杂性。它处理大型模型和团队。在定义了领域domain和子域subdomains之后，在这里实现代码。
有界上下文实际上表示在其中定义并适用某个子域的边界。在这里，特定的子域有意义，而其他则没有意义。一个实体在不同的上下文中可以具有不同的名称。当有界上下文中的子域发生更改时，整个系统也不必更改。这就是开发人员在上下文之间使用适配器的原因。
6.无所不在的语言：通用语言是一种方法，它指的是领域专家和开发人员在谈论他们正在使用的领域时所使用的相同语言。这是必要的，因为项目可能会遇到语言中断的严重问题。发生这种情况是因为领域专家使用了自己的行话。同时，技术专业人员使用他们自己的术语来谈论该领域。
日常讨论中使用的术语与代码中使用的术语之间存在差距。这就是为什么必须定义每个人都使用的一组术语的原因。通用语言中的所有术语都是围绕领域模型构建的。
7.实体：实体是数据和行为的组合，例如用户或产品。它们具有身份，但是代表具有行为的数据点。
8.值对象和聚合：值对象具有属性，但不能单独存在。例如，送货地址可以是值对象。大型而复杂的系统具有无数的实体和值对象。这就是为什么领域模型需要某种结构。这会将它们分为易于管理的逻辑组。这些组称为集合。它们代表了相互连接的对象的集合，目的是将它们视为一个单位。而且，它们也具有聚合根。这是聚合之外的任何对象都可以引用的唯一实体。
9.领域服务：域服务是一个附加层，其中还包含域逻辑。它是域模型的一部分，就像实体和值对象一样。同时，应用程序服务是不包含业务逻辑的另一层。但是，这里是在域模型上方协调应用程序的活动。
10.Repository存储资料库：存储库模式是业务实体的集合，可简化数据基础结构。它从基础结构方面释放了域模型。分层概念强制将关注点分离。
领域驱动设计示例
例如，如果我们使用电子商务应用程序，则业务领域将是处理订单。当客户想要下订单时，他们首先需要检查产品。然后，他们选择所需的商品，确认订单，选择运输类型并付款。然后，该应用会处理客户端提供的数据。
因此，用户应用程序将由以下几层组成：
1.用户界面：客户可以在这里找到下订单所需的所有信息。在电子商务案例中，这就是产品所在的位置。该层将信息提供给客户端并解释其行为。
2.应用层：该层不包含业务逻辑。这是将用户从一个用户界面引导到另一个用户界面屏幕的部分。它还与其他系统的应用程序层进行交互。它可以执行简单的验证，但不包含与域相关的逻辑或数据访问。其目的是组织和委托域对象来完成其工作。而且，它是其他有界上下文可访问的唯一层。
3.领域层：这就是业务领域的概念所在。该层具有有关业务案例和业务规则的所有信息。这也是实体所在的位置。如前所述，实体是数据和行为的组合，例如用户或产品。
它们具有通过唯一键保证的唯一身份，即使其属性发生更改，它们仍然保留。例如，在电子商务商店中，每个订单都有唯一的标识符。它必须经过确认和发货之类的若干操作才能被视为一个实体。
另一方面，值对象没有唯一的标识符。它们代表各种实体可以共享的属性。例如，这可以是不同客户的相同姓氏。
这部分还包含具有定义的操作行为的服务，这些服务不必属于任何域。但是，它们仍然是业务领域的一部分。服务根据普遍使用的语言命名。他们不应剥夺实体并重视对象的明确责任心和行动。客户应该能够使用任何给定的服务实例。在应用程序的生命周期中该实例的历史记录应该不是问题。
最重要的是，域层位于业务应用程序的中心。这意味着应将其与其余各层分开。它不应该依赖于其他层或它们的框架。
4.基础设施层：该层支持其他层之间的通信，并且可以包含UI层的支持库。
领域驱动设计的优势
- 通讯更简单。多亏了无处不在的语言，开发人员和团队之间的交流变得更加容易。由于无所不在的语言可能包含开发人员所引用的简单术语，因此不需要复杂的技术术语。
- 更大的灵活性。由于DDD是面向对象的，因此有关该域的所有内容均基于该对象，并且对象是模块化和笼状的。因此，可以定期修改和改进整个系统。
- 该域位于UI / UX之前。由于域是中心概念，因此开发人员将构建适合于特定域的应用程序。这不会是另一个以界面为中心的应用程序。尽管您不应该忽略UX，但是使用DDD方法意味着该产品将完全针对直接连接到域的用户。
领域驱动设计的缺点
- 需要深入的领域知识。即使是从事开发工作的技术最先进的团队，团队中也至少要有一位领域专家，他们了解作为应用程序中心的主题领域的精确特征。有时，需要一些完全了解该领域的团队成员并入开发团队。
- 包含重复性做法。尽管许多人会说这是一个优势，但是域驱动的设计包含许多重复性的实践。DDD鼓励使用持续集成来构建功能强大的应用程序，这些应用程序可以在必要时进行自我调整。许多组织可能在使用这些方法时遇到困难。更具体地说，如果他们以前的经验通常与诸如瀑布模型之类的较不灵活的增长模型相关联。
- 对于高科技项目，它可能不是最好的方法。域驱动的设计非常适合具有复杂业务逻辑的应用程序。但是，对于领域复杂度较小但技术复杂度较高的应用程序，它可能不是最佳解决方案。对于面向业务的领域专家来说，技术复杂性很高的应用程序可能会非常具有挑战性。这可能会导致许多限制，而这些限制可能并非所有团队成员都能解决。
结论
域驱动设计是一种解决特定域模型的软件工程方法。通过将执行与关键业务原则联系起来，该解决方案绕过业务模型。
域专家和开发团队之间的通用术语包括域逻辑，子域，有界上下文，上下文映射，域模型和无处不在的语言，以作为协作和改进应用程序模型以及解决任何与域相关的挑战的方式。
在本文中，我们想定义围绕域驱动设计的核心概念。此外，我们想对它们进行解释，并添加该方法的优点和缺点。这样，我们希望可以帮助您确定这是否是适合您的业务和应用程序的方法。
微服务提供了一些严重的优于传统的架构，提供可扩展性，可访问性和灵活性。此外，由于每个微服务都是一个松散耦合的服务，只有一种责任感，因此这种方法使开发人员能够集中精力。