基于领域模型的微服务划分--实战案例解析，java高级工程师面试题

ℹ️　聚合可以包含单个实体且不包含子实体。 聚合的定义由事务边界确定。

领域服务和应用服务。 在 DDD 术语中，服务是实现某种逻辑且不保存任何状态的对象。 Evans 区分 域服务（用于封装域逻辑）和 应用程序服务（提供技术功能，如用户身份验证或发送短信）。 领域服务通常用于对跨多个实体的行为建模。

ℹ️　软件开发中广泛使用了“服务”一词。 此处的定义不直接与微服务相关。

领域事件。 发生某种情况时，可以使用领域事件来通知系统的其他部件。 顾名思义，领域事件应该表示领域中发生的某些情况。 例如，“在表中插入了记录”不是领域事件。 “已取消投递”是领域事件。 领域事件与微服务体系结构密切相关。 由于微服务为分发式且不共享数据存储，领域事件可为微服务提供相互协调的途径。

文章 服务间通信 更详细地讨论了异步消息传送。

还有其他几种 DDD 模式未在此处列出，包括工厂、Repository和模块。 开发微服务时，这些模式可能十分有用；但是，在微服务之间设计边界时，它们作用不大。

从领域模型到微服务

微服务的适当大小是什么？ 我们经常听到有人说，“不要太大，也不要太小”— 这句话绝对正确，但实际上没有太大意义。 但是，如果从一个精心设计的领域模型着手，则规划出微服务就容易得多。

在为限界上下文标识了一组实体、聚合和领域服务之后，我们可以从领域模型转到应用程序设计。 下面是一个用于从域模型派生微服务的方法。

1. 从限定上下文开始。 通常，微服务中的功能不应跨多个限定上下文。 根据定义，限界上下文标记特定领域模型的边界。 如果你发现微服务混用了不同的领域模型，可能意味着需要重新进行领域分析以优化领域模型。

2. 接下来，查看领域模型中的聚合。 聚合通常是微服务的适当候选项。 合理设计的聚合能够体现一个设计优良的微服务的许多特征，例如：

• 聚合派生自业务要求，而不是数据访问或消息传递等技术因素。

• 聚合应具有较高的功能内聚性。

• 聚合是持久性的边界。

• 聚合应为松散耦合。

3. 域服务也是微服务的适当候选项。 域服务是跨多个聚合的无状态操作。 典型的示例是涉及多个微服务的工作流。 我们将在无人机快递应用程序中看到此示例。

4. 最后，考虑非功能性要求。 分析团队规模、数据类型、技术、可伸缩性、可用性和安全性需求等因素。 这些因素可能导致需要进一步将微服务分解成两个或更多个较小服务，或者相反的，将多个微服务合并成一个。

在应用程序中标识微服务之后，请根据以下条件验证设计：

• 每个服务承担单一责任。

• 服务之间不存在琐碎的调用。 如果将功能拆分成两个服务会导致它们过度琐碎，该症状的原因可能是这些功能属于同一个服务。

• 每个服务足够小，独立工作的小团队即可构建它。

• 两个或更多个服务的部署不应该存在相互依赖的关系。 应该始终可以在不重新部署其他任何服务的情况下部署某个服务。

• 服务未紧密耦合，可独立演变。

• 服务边界不会造成数据一致性或完整性方面的问题。 有时，必须通过将功能放入单个微服务来保持数据一致性