一个好的服务的判定标准有很多------功能性、性能、可用性、可维护性、健壮性、协作性。在这一章节中，作者希望读者能专注在两个重要的概念上：松耦合和高内聚。
探讨基于低耦合高内聚原则的服务划分。
松耦合
一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息。
微服能独立修改以及部署而不需要修改其他服务。
高内聚
把相关的行为聚集在一起，不相关的行为放在别处。这样要改变某个行为时，只需要在一个地方进行修改。
限界上下文
"限界上下文"是领域驱动设计DDD种的一个核心概念，用于解决复杂业务系统中不同业务模块的边界划分和写作的问题，其核心思想是：将一个庞大系统拆分为多个明确边界的小业务领域，每个领域内部使用统一的语言和模型，并通过清晰的接口与其他领域交互。
这个"明确边界的小业务领域"，就可以是"xxx上下文"。借助"限界上下文"对业务边界进行描述会比较准确，例如：
电商系统，可以简单分出来------
订单上下文：关注订单创建、支付状态、物流跟踪。(改变订单的行为只需要在订单上下文中进行，且不需要关注其他上下文，在必要的时候进行上下文通信即可)
库存上下文：管理商品库存的增减、预留和同步。
会员上下文：处理用户积分、等级和优惠券。
交互方式：订单创建时通过事件（如 OrderPlacedEvent）通知库存系统扣减库存。
"限界上下文"就是这样一个划分业务的逻辑边界的概念工具。
开篇有讲到，微服务是"协同工作的小而自洽的服务"，如何"小的刚刚好"，即"如何拆分为明确边界的小业务领域"，最佳实践就是一个微服务对应一个"限界上下文"------微服务和限界上下文保持一致。
但是注意不要过度拆分，将单一业务拆分为多个上下文，我们核心原则还是低耦合高内聚。
服务拆分的边界可以理解为一个领域框，框内应该是相关性强的业务。
专家级程序员强调的行业经验应当就有领域划分边界的经验。
逐步划分上下文
继续学怎么划分上下文。
在引入"限界上下文"辅助划分高度相关的业务内容为微服务后，需要理解的是------上下文的颗粒度应该根据组织结构看来决定，组织结构和软件架构会互相影响。
例如仓库系统可以拆分为：订单处理、货物接收、库存管理
财务系统与仓库系统进行通信获取库存等级，是直接与仓库系统进行通信，还是与具体的库存管理通信，还是与仓库提供通信，这可能取决于开发系统的组织架构。
关于业务概念的沟通
设计微服务时，需要考虑微服务如何就一个业务概念进行通信。
通信方式同步还是异步，性能要求如何，系统复杂度怎么控制？这些都与业务概念相关，沟通的原则是尽量可靠、安全、可拓展。