如何确定微服务的边界
---建模
1. 什么样的服务是好的服务
1) 松耦合：修改一个服务不需要修改另外一个服务，保证服务是可以独立修改和部署
如何做到松耦合：
a. 限制两个服务之间的不同调用形式的数量。
2) 高内聚：改变某个行为，最好能够只在一个地方进行修改
松耦合、高内聚的关键是找到服务的边界。
2. 通过对现实世界的建模确定服务的边界
领域驱动设计：Eric Evans的《领域驱动设计》（最新的中文修订版在亚马逊有售），专注于如何对现实世界领域的建模。
该书中对划分服务边界最重要的一个术语：限界上下文
1) 定义：一个由显式边界限定的特定职责（不像人话）
2) 一个领域内有一个或者多个限界上下文
3) 任何一个限界上下文都可以分成两部分：
a. 需要和外部通信
b. 不需要和外部通信
4) 每个上下文都有明确的接口，接口用于和外部领域的通信
5) 和细胞类似：细胞膜定义了什么在细胞内，什么在细胞外，什么物质可以通过细胞膜
共享的隐藏模型
1) 定义：两个限界上下文之间共享的模型
2) 也存在内部和外部两种表现形式，内外的数据不同：
例如库存项作为在财务和仓库两个限界上下文里共享的模型，尽管仓库内部有对应的模型表示库存，但是不会把该模型的全部数据暴露给财务。
3) 同样的名字在不同的上下文有着完全不同的含义：
比如退货，在仓库里意味着要重新入库，而在客户的上下文力，意味着打包、寄送快递，然后等待退款
模块和服务
服务的边界划分错误后，后续修复的代价会很大。
刚开始开发时，利用同一个进程内的模块作为解耦的方式，也是一种选择。每个边界上下文用一个模块表示，同时使用共享和隐藏模型。
这意味着先开发单块架构。对业务熟悉后，或者系统稳定后，再把单块架构转换成微服务架构。
模块是微服务的绝佳候选。
3. 如何划分上下文
应该按照业务建模
1) 首先考虑业务的功能，这个上下文是做什么的？
建模服务时，应该将这些功能作为关键的操作提供给其它服务
2) 然后考虑共享的数据，“它需要什么样的数据”。
只考虑数据模型的共享，会导致贫血的服务（只基于crud的服务）。
3) 逐步划分：
a. 首先识别出粗粒度的上下文，如仓库，财务
b. 进一步划分嵌套的上下文，如仓库又可分为：订单处理、库存管理、货物接受等。
c. 根据组织架构决定使用嵌套的方式（如仓库的粗粒度上下文里嵌套订单处理、库存管理及货物接受等细粒度上下文）还是分离的方式（取消仓库上下文，之间将仓库内部的上下文提升到顶层上下文的层次。
订单处理、货物接收及库存管理由同一个团队维护，使用嵌套方式
由不同的团队维护，使用分离方式
嵌套：
分离
4. 划分上下文容易犯的错误：技术建模
1) 按照技术接缝对服务进行划分，会导致把上下文内部的api暴露出去，导致紧耦合。所谓的洋葱架构（水平分层架构）
