微服务的适当大小是什么？ 人们常说“不要太大，也不要太小”，这固然是正确的说法，但实际上没有太大意义。 但是，如果从一个精心设计的领域模型着手，则规划出微服务就容易得多。
本文以无人机交付服务为例进行讨论。 可以在此处阅读有关方案和相应参考实现的详细信息。
从领域模型到微服务
在上一篇文章中，我们为无人机交付应用程序定义了一组边界上下文。 然后，我们更详细地探讨了其中的某个边界上下文（“交货”边界上下文），并为该边界上下文标识了一组实体、聚合和领域服务。
现在，我们可以从领域模型转到应用程序设计。 下面是一个用于从域模型派生微服务的方法。
从限定上下文开始。 通常，微服务中的功能不应跨多个限定上下文。 根据定义，边界上下文标记特定领域模型的边界。 如果你发现微服务混用了不同的领域模型，可能意味着需要重新进行领域分析以优化领域模型。
接下来，查看领域模型中的聚合。 聚合通常是微服务的适当候选项。 合理设计的聚合能够体现一个设计优良的微服务的许多特征，例如：
- 聚合派生自业务要求，而不是数据访问或消息传递等技术因素。
- 聚合应具有较高的功能内聚性。
- 聚合是持久性的边界。
- 聚合应为松散耦合。
域服务也是微服务的适当候选项。 域服务是跨多个聚合的无状态操作。 典型的示例是涉及多个微服务的工作流。 我们将在无人机交付应用程序中看到此示例。
最后，考虑非功能性要求。 分析团队规模、数据类型、技术、可伸缩性要求、可用性要求和安全要求等因素。 这些因素可能导致需要进一步将微服务分解成两个或更多个较小服务，或执行相反的操作，即，将多个微服务合并成一个。
在应用程序中标识微服务之后，请根据以下条件验证设计：
- 每个服务承担单一责任。
- 服务之间不存在琐碎的调用。 如果将功能拆分成两个服务会导致它们过度琐碎，该症状的原因可能是这些功能属于同一个服务。
- 每个服务足够小，独立工作的小团队即可构建它。
- 两个或更多个服务的部署不应该存在相互依赖的关系。 应该始终可以在不重新部署其他任何服务的情况下部署某个服务。
- 服务未紧密耦合，可独立演变。
- 服务边界不会造成数据一致性或完整性方面的问题。 有时，必须通过将功能放入单个微服务来保持数据一致性。 话虽如此，但应该是否确实需要强一致性。 可通过某些策略来解决分布式系统中的最终一致性，分解服务的好处通常比管理最终一致性所存在的挑战更具效益。
最重要的是，必须追求实用，并记住领域驱动的设计是一个迭代过程。 如果有疑问，可以从更粗粒度的微服务入手。 将微服务拆分成两个较小服务比跨多个现有微服务来重构功能更方便。
示例：为无人机交付应用程序定义微服务
回顾一下，前面开发团队已标识四个聚合（“交付”、“包裹”、“无人机”和“帐户”）和两个领域服务（“计划程序”和“监督程序”）。
“交付”和“包裹”是微服务的突出候选项。 “计划程序”和“监督程序”协调其他微服务执行的活动，因此，将这些领域服务实施为微服务比较有利。
“无人机”和“帐户”比较特别，它们属于其他边界上下文。 一种做法是让“计划程序”直接调用“无人机”和“帐户”边界上下文。 另一种做法是在“交货”边界上下文中创建“无人机”和“帐户”微服务。 这些微服务通过公开更适合“交货”上下文的 API 或数据架构，在边界上下文之间充当中介。
“无人机”和“帐户”边界上下文的详细信息超出了本指南的范畴，因此我们在参考实现中创建了它们的模拟服务。 但在此情况下，需考虑一些因素：
直接调入其他边界上下文会产生多大的网络开销？
其他边界上下文的数据架构是否适用于此上下文，或者，专门针对此边界上下文定制一个架构是否更好？
其他边界上下文是否为旧式系统？ 如果是，则可以创建一个充当防腐层的服务，用于在旧式系统与新式应用程序之间进行转换。
团队结构是什么？ 是否能够方便地与负责其他边界上下文的团队通信？ 如果不是，创建一个充当两个上下文之间的中介的服务可能有助于降低跨团队通信所产生的成本。
到目前为止，我们尚未考虑任何非功能性要求。 考虑到应用程序的吞吐量要求，开发团队决定创建一个负责引入客户端请求的独立“引入”微服务。 此微服务将传入的请求放入缓冲区进行处理，以此实施负载调节。 计划程序将从缓冲区读取请求，并执行工作流。
非功能性要求使得团队必须额外创建一个服务。 到目前为止，所有服务都与包裹的实时安排和交付过程相关。 但是，系统还需要在长期存储中存储每项交付的历史记录，以进行数据分析。 团队认为这是交付服务的责任。 但是，历史分析与现行操作的数据存储要求有较大的差别（请参阅数据注意事项）。 因此，团队决定创建一个独立的交付历史记录服务，用于侦听来自交付服务的 DeliveryTracking 事件，并将这些事件写入长期存储。
下图展示了现阶段的设计：
下载此体系结构的 Visio 文件。
后续步骤
此时，应对设计中每个微服务的用途和功能有一个清晰的认识。 现在可以构建系统。