原文
引言
- 本文中，我们将学习如何将微服务分解为微服务架构。我们将专注于识别和分解具有不同模式和实践的电子商务领域的微服务。
- 在本文结束时，您将学习如何通过应用各种微服务分解模式（如按业务能力分解、按子域分解和限界上下文模式）来分解微服务，并设计电子商务微服务应用程序。
目录
- 了解电子商务领域
- 分解微服务架构并识别微服务
分解微服务架构路径
让我解释一下我们的分解路径，我们将遵循一些步骤；
- 我们将进行电子商务领域分析，以定义您的微服务边界。
- 我们将使用 DDD、限界上下文和其他分解策略，如按业务能力分解、按子域分解微服务模式
- 最后，我们将确定微服务边界并重构我们当前的设计。
按业务能力分解
- 我们的单体应用是大而复杂的应用，想用微服务架构。通过微服务架构，我们将应用程序拆分为一组松散耦合的服务，以加速软件开发过程。
如何将应用程序分解为服务？
微服务的分解有一些先决条件。
- 服务必须具有凝聚力。服务应该实现一小组密切相关的功能。
- 服务必须是松散耦合的——每项服务都作为封装其实现的 API。
“按业务能力分解”模式提供了这一点；
- 定义业务能力对应的服务。
- 业务能力是业务架构建模的概念。
- 业务服务应该产生价值。
例如： Order Management 对订单负责，Customer Management 对客户负责。
如果我们看一下我们的电子商务应用程序域，业务功能可以像图像中包含的那样：
- 产品管理
- 库存管理
- 订单管理
- 发货管理
所以我们可以根据他们的业务能力分解我们的微服务。
微服务分解模式——按子域分解
- 在此模式中，我们将在将应用程序分解为微服务时使用按子域模型分解。同理我们有2个微服务分解的先决条件；服务必须是内聚的，服务必须是松散耦合的。
- 为了应用按子域分解模型，我们应该定义与域驱动设计 (DDD) 子域对应的服务。 DDD 是指应用程序的问题空间业务作为领域。
- 一个域由多个子域组成。每个子域对应于业务的不同部分。
如果我们看一下我们的电子商务应用程序域，在线商店的子域包括：
- 产品管理
- 库存管理
- 订单管理
- 发货管理
但是要识别这些域和子域，我们应该正确理解 DDD 和限界上下文模式。
限界上下文模式（领域驱动设计 — DDD）
我们将看到 DDD — 限界上下文模式，这是我们在分解微服务时主要使用的主要模式之一。设计微服务的最佳方式之一是使用 DDD 限界上下文模式。所以我们应该正确理解Bounded Context。
在我们开始之前，让我们解释下什么是 DDD？
什么是 DDD？
我们可以说，需要高度合作并且天生具有一定复杂性的领域被称为协作领域。通常情况下，DDD 是这种特征领域的更适合解决方案。
DDD 有两个阶段，战略和战术 DDD。
DDD的战略
在战略性 DDD 中，我们定义系统的大规模模型，定义到业务规则。战略性 DDD 确定允许设计松散耦合单元和它们之间的上下文映射的规程。
DDD的战术
战术DDD侧重于实现，并提供我们可以用来构建软件实现的设计模式。这些设计模式包括实体、聚合、值对象、存储库和领域服务等概念。我们不会在此详细介绍，因为我们专注于DDD和微服务。
DDD通过创建一个共同的语言来增加大型技术团队之间的协作，以应对不断变化的业务规则。DDD领域定义了一种方法，该方法具有自己的通用语言，并将边界划分为特定、独立的组件。
这种通用语言被称为统一语言，独立的单元被称为有界上下文。
因此，我们可以说DDD是在分析复杂系统推荐使用的方法。
-
DDD通常解决复杂问题的方法是将问题分解成较小的部分，并专注于那些相对容易的小问题。一个复杂领域可能包含子领域。其中一些子领域可以结合并归为共同规则和责任。
-
因此，我们可以说子域的组是有界上下文。有界上下文是紧密相关范围的分组，我们可以称之为逻辑边界。因此，逻辑边界可以具有共同的业务规则，并通过集群表达责任限制。
-
我们可以说，有界上下文是代表复杂领域中自洽且尽可能独立的较小问题粒子的逻辑边界。
您可以在上图中看到，有 2 个限界上下文销售和支持上下文。这些是潜在的微服务通过这种方式分隔的逻辑边界。
识别每个微服务的限界上下文边界
那么我们如何识别限界上下文呢？
- 为了识别有界上下文，我们应该使用 DDD。而在 DDD 中，我们应该使用 Context Mapping 模式来识别有界上下文。
- 使用上下文映射模式，我们可以识别应用程序中的整个限界上下文及其逻辑边界。所以答案是上下文映射，上下文映射是一种定义域之间逻辑边界的方法。
我们可以根据上图来分析：
- 首先，我们应该通过与领域专家交谈并使用一些线索来识别限界上下文。一旦我定义了限界上下文，我们就不应该再认为它们是不可变的了。
- 通过与领域专家交谈重新制定你的限界上下文，并考虑根据不断变化的条件进行重构。
例如在这张图片中有几个限界上下文，比如：
- Customers,
- Orders
- Payment 在限界上下文中有子域，一些子域表示相同的数据，但由于领域专家领域的不同而命名不同。这意味着我们应该针对他们的专业领域讨论几位领域专家
限界上下文 == 微服务？
- 可以说，这个问题在任何情况下都没有正确答案。
- 一个微服务可以代表一个有界上下文或其部分。换句话说，一个有界上下文可以创建多个微服务。这完全是基于微服务对可扩展性和独立性的需求而做出的决定。
- 虽然有界上下文定义了领域的边界，但微服务以与 BC 领域相同的方式确定技术和组织边界。
- 但是，当从有界上下文定义微服务时，仍然可以使用这种方法。因为这类似于微服务的定义：它是自治的，并负责某些领域能力。
所以这就是为什么上下文映射和限界上下文模式是识别微服务的好方法。我们在分解微服务时也会遵循这种模式。
使用域分析对微服务建模
-
我们将使用领域分析来对微服务进行建模。这意味着我们将结合我们新学习的项目并将我们的电子商务应用程序微服务分解在一起。但在此之前让我们制定一个计划。
-
我们说过，微服务要按照业务能力来设计，要松耦合，服务自治。微服务是松散耦合的，这意味着我们可以在不影响其他服务的情况下更改特定的微服务。每个服务都可以独立更改。
领域驱动设计 (DDD) 提供了一套方法论，我们可以遵循这些原则并创建设计良好的微服务。我们应该遵循 DDD-Bounded Context，它遵循 Context Mapping Pattern 并按子域模型模式进行分解。
因此，我们将完成以下步骤，将它们应用到我们的电子商务应用程序中：
- 我们将从分析业务领域开始，以了解应用程序的功能需求。
- 接下来，我们将使用以下最佳实践定义域的有界上下文。每个限界上下文都包含一个域模型，其中包含较大应用程序的子域。
- 通过限界上下文，我们将应用战术 DDD 模式来定义实体、聚合和领域服务。
在这些步骤结束时，我们可以识别应用程序中的微服务。
分析电子商务领域——用例
- 现在我们要谈谈我们的项目领域。因此，我们将通过所有用例了解电子商务领域
- 在分析我们的域时，我们将应用哪种架构并不重要。因此，第一步始终应该是了解您的领域并将其分解成小块。
- 我们将遵循 DDD-Bounded Context，它遵循 Context Mapping Pattern 并按子域模型模式进行分解。
开始我们的项目
- 该项目将是电子商务 Web 应用程序。所以我们应该定义我们的基本用例分析。了解您将开发什么非常重要，定义您的用例也很重要
- 有几种分析电子商务领域的方法；我们可以遵循几个步骤，例如；
- 需求和建模
- 识别用户故事
- 识别用户故事中的名词
- 识别用户故事中的动词
这样之后我们就可以把它们放在一起形成对象交互图。如果我们选择微服务架构，这些图将是我们潜在的微服务。
- 现在我们将启动一个小型电子商务应用程序。这就是为什么开始最低要求是好的原因；
功能要求
- 产品列表
- 按品牌和类别过滤产品
- 将产品放入购物车
- 申请折扣优惠券并查看购物车中所有商品的总费用
- 检查购物车并创建订单
- 列出我的旧订单和订单项目历史
定义这些流程的另一种方法是将它们转换为用例项；
用户故事
- 作为用户，我想列出产品
- 作为用户，我想按品牌和类别过滤产品
- 作为用户，我想将产品放入购物车，以便以后快速结帐
- 作为用户，我想申请优惠券以获得折扣，并查看我购物车中所有商品的总费用
- 作为用户，我想结帐购物车并创建订单
- 作为用户，我想列出我的旧订单和订单项目历史记录
- 作为用户，我想以用户身份登录系统，系统应该记住我的购物车项目
我们已经了解了我们的电子商务领域，请写下我们的功能需求和用例。
分析电子商务领域——名词和动词
我们将要分析电子商务领域——名词和动词。在前面的标题中，我们创建了用户故事。所以现在我们可以在用户故事中选择名词和动词并创建图表。
如果我们扩展用户故事并从故事中提取名词和动词，那么我们将看到下图。
我正在寻找将成为我的主要对象的名词而不是属性。
名词:
- Customer
- Order
- Order Details
- Product
- Shopping Cart
- Shopping Cart Items
- Supplier
- User
- Address
- Brand
- Category
这些名词将帮助我们找到子域和限界上下文。我们在这里也有动词来理解域之间的通信。
动词:
- 列出应用分页的产品
- 按品牌、类别和供应商筛选产品
- 在详细信息屏幕中查看产品所有信息
- 将产品放入购物车
- 查看所有项目的总成本
- 查看每件商品的总成本
- 带有购买步骤的结帐订单
- 指定送货地址
- 为送货地址指定送货单
- 指定信用卡信息
- 支付物品
- 告诉我有多少货品
- 接收订单确认邮件
- 列出订单和详细历史记录
- 登录系统，记住购物车商品
通过使用上面的名词和动词，我们可以将这样的图表放在一起：
正如您所看到的，我们现在有域图，接下来我们可以定义潜在的微服务
识别和分解电子商务领域的微服务
我们将为电子商务领域识别和分解微服务。因此，如果您按照我们在前面的说明中应用的相同步骤进行操作，我们将看到这个新的微服务；
总结
- 我们已经了解了如何识别和分解电子商务领域的微服务，现在应该专注于微服务架构！！
- 我们应该将我们的架构发展为微服务架构，以适应业务调整，加快上市时间并处理更大的请求。
