在确定每个微服务的模型边界和大小时，目标并不是尽可能实现最细粒度的分离，尽管如果可能的话，您应该倾向于使用较小的微服务。相反，您的目标应该是在您的领域知识的指导下实现最有意义的分离。重点不在于规模，而在于业务能力。此外，如果基于大量依赖关系的应用程序的某个特定区域需要明显的内聚，这也表示需要单个微服务。内聚性是一种识别如何分离或组合微服务的方法。最终，当您获得更多关于域的知识时，您应该迭代地调整微服务的大小。找到合适的尺寸不是一蹴而就的过程。
Sam Newman是公认的microservices的发起人，也是《构建microservices》一书的作者，他强调应该根据前面介绍的有界上下文（BC）模式（领域驱动设计的一部分）来设计microservices。有时，BC可以由多个物理服务组成，但反之亦然。
具有特定域实体的域模型应用于具体的BC或微服务中。业务连续性定义了域模型的适用性，并使开发团队成员对什么必须具有内聚性和什么可以独立开发有一个清晰和共享的理解。这些都是微服务的相同目标。
另一个通知您的设计选择的工具是Conway's law，它声明一个应用程序将反映产生它的组织的社会边界。但有时恰恰相反——公司的组织是由软件组成的。你可能需要推翻康威的法律，按照你希望公司组织的方式建立边界，倾向于业务流程咨询。
要识别有界上下文，可以使用称为上下文映射模式的DDD模式。使用上下文映射，可以标识应用程序中的各种上下文及其边界。例如，每个小的子系统都有不同的上下文和边界。上下文映射是定义和明确域之间边界的一种方法。BC是自治的，包含单个域的详细信息（如域实体），并定义与其他BC的集成合同。这类似于微服务的定义：它是自治的，实现了一定的域功能，并且必须提供接口。这就是为什么上下文映射和有界上下文模式是识别微服务的域模型边界的好方法。
在设计大型应用程序时，您将看到它的域模型是如何被分割的——例如，来自目录域的域专家将以不同于装运域专家的方式命名目录域和库存域中的实体。或者，当客户关系管理专家想要存储客户的每一个细节时，用户域实体在大小和属性数量上可能不同于订购域专家，订购域专家只需要客户的部分数据。在与大型应用程序相关的所有域中，很难消除所有域术语的歧义。但最重要的是你不应该试图统一术语。相反，接受每个领域提供的差异和丰富性。如果您试图为整个应用程序建立一个统一的数据库，那么尝试使用统一的词汇表将很困难，而且对任何一个多域专家来说都不太合适。因此，BCs（实现为microservices）将帮助您澄清在何处可以使用某些域术语，以及在何处需要拆分系统并创建具有不同域的附加BCs。
如果域模型之间很少有强关系，并且在执行典型的应用程序操作时通常不需要合并来自多个域模型的信息，那么您将知道每个BC和域模型的边界和大小都是正确的。
对于每个微服务的域模型应该有多大的问题，最好的答案可能是：它应该有一个尽可能独立的自治BC，使您能够在不需要不断切换到其他上下文（其他微服务的模型）的情况下工作。在图10中，您可以看到多个微服务（多个BCs）各自有自己的模型，以及如何定义它们的实体，这取决于应用程序中每个已标识域的特定需求。
图10展示了一个与在线会议管理系统相关的示例场景。同一实体显示为“用户”、“买方”、“付款人”和“客户”，具体取决于有界上下文。基于领域专家为您定义的域，您已经确定了几个可以实现为微服务的bc。如您所见，有些实体只存在于一个microservice模型中，如Payment microservice中的Payments。这些将很容易实施。
但是，您也可能有具有不同形状的实体，但在多个微服务的多个域模型中共享相同的标识。例如，用户实体在会议管理微服务中标识。具有相同身份的同一用户是Ordering microservice中指定的买家，或Payment microservice中指定的付款人，甚至是Customer Service microservice中指定的客户。这是因为，取决于每个领域专家使用的普遍语言，用户可能有不同的视角，即使具有不同的属性。名为“会议管理”的微服务模型中的用户实体可能具有其大部分个人数据属性。但是，在microservice Payment中以Payer形式或在microservice Customer Service中以Customer形式的同一用户可能不需要相同的属性列表。
类似的方法如图11所示。
图11 将传统数据模型分解为多域模型
在有界上下文之间分解传统数据模型时，可以在每个有界上下文中拥有具有不同属性的共享同一标识的不同实体（买方也是用户）。您可以看到用户如何以用户实体的形式出现在会议管理微服务模型中，并且在定价微服务中以买方实体的形式出现，当用户实际上是买方时，还可以看到用户的其他属性或详细信息。根据要解决的问题或上下文，每个微服务或BC可能不需要与用户实体相关的所有数据，而只需要其中的一部分。例如，在Pricing microservice模型中，您不需要用户的地址或名称，只需要ID（身份）和状态，这将在为每个买家定价座位时对折扣产生影响。
Seat实体在每个域模型中具有相同的名称，但属性不同。但是，与用户和买方一样，座椅共享基于相同ID的标识。
基本上，在多个服务（域）中存在一个用户的共享概念，所有服务（域）都共享该用户的身份。但是在每个域模型中，可能有关于用户实体的其他或不同的详细信息。因此，需要有一种方法将用户实体从一个域（微服务）映射到另一个域。
不在域之间共享具有相同数量属性的同一用户实体有几个好处。一个好处是减少重复，这样microservice模型就不需要任何数据。另一个好处是拥有一个主微服务，该主微服务拥有每个实体的特定类型的数据，因此对该类型数据的更新和查询仅由该微服务驱动。
架构师的宝库，每天一篇，开拓你的视野和深度。分享企业架构，业务架构，应用架构，数据架构，技术架构，安全架构等。讨论架构框架,规划，治理,标准，落地。交流新兴的架构风格和模型。如微服务，事件驱动，微前端，大数据，数仓，物联网，人工智能架构。
前端后端一锅端，数据物联区块链，AI AR 和VR，分析 安全 元宇宙。全栈开发Java,Python,Go,Groovy,Kotlin,C#,Node,TypeScript,JavaScript,Rust, Swift,R,Ruby。
首席数字化转型官
交流数字化转型，创新和整合。帮助CIO,CDO,CDTO成长。关注数字化方法，流程，框架，案例以及趋势。探讨业务架构规划，IT建设和数字化落地。聊产品，研发，营销，销售，供应链，计划，工厂，财务，税务等数字化领域。
