「第二部:容器和微服务架构」(8) 识别每个微服务的领域模型边界

在确定每个微服务的模型边界和大小时，目标并不是尽可能实现最细粒度的分离，尽管如果可能的话，您应该倾向于使用较小的微服务。相反，您的目标应该是在您的领域知识的指导下实现最有意义的分离。重点不在于规模，而在于业务能力。此外，如果基于大量依赖关系的应用程序的某个特定区域需要明显的内聚，这也表示需要单个微服务。内聚性是一种识别如何分离或组合微服务的方法。最终，当您获得更多关于域的知识时，您应该迭代地调整微服务的大小。找到合适的尺寸不是一蹴而就的过程。

Sam Newman是公认的microservices的发起人，也是《构建microservices》一书的作者，他强调应该根据前面介绍的有界上下文（BC）模式（领域驱动设计的一部分）来设计microservices。有时，BC可以由多个物理服务组成，但反之亦然。

具有特定域实体的域模型应用于具体的BC或微服务中。业务连续性定义了域模型的适用性，并使开发团队成员对什么必须具有内聚性和什么可以独立开发有一个清晰和共享的理解。这些都是微服务的相同目标。

另一个通知您的设计选择的工具是Conway's law，它声明一个应用程序将反映产生它的组织的社会边界。但有时恰恰相反——公司的组织是由软件组成的。你可能需要推翻康威的法律，按照你希望公司组织的方式建立边界，倾向于业务流程咨询。

要识别有界上下文，可以使用称为上下文映射模式的DDD模式。使用上下文映射，可以标识应用程序中的各种上下文及其边界。例如，每个小的子系统都有不同的上下文和边界。上下文映射是定义和明确域之间边界的一种方法。BC是自治的，包含单个域的详细信息（如域实体），并定义与其他BC的集成合同。这类似于微服务的定义：它是自治的，实现了一定的域功能，并且必须提供接口。这就是为什么上下文映射和有界上下文模式是识别微服务的域模型边界的好方法。