微服务架构设计 第二步: 分析微服务的边界上下文 (Bounded Context)

2016.9.10, 深圳, Ken Fang

当特性负责人, 将特性的所有业务活动均分析出, 其各自的基本流, 扩展流与异常流之后, 特性负责人便可经由组合基本流, 扩展流与异常流, 而分析出从外部使用者或外部产品的视角, 有价值的端到端的业务场景切片后, 特性负责人便可将各业务场景切片中, 共同的场景提取出, 成为所谓的 infrastructure services。

也就是说:

A. 对外部的使用者或外部的产品而言, 有价值的端到端的业务场景切片, 便构成了所谓的 functional services; 可供外部使用者或外部产品经由 api layer 来调用。

B. 各 functional services 中所存在的共同场景, 便构成了所谓的 infrastructure services; 只供 functional services 调用, 外部使用者或外部产品是无法经由 api layer 来调用的。  

现在的问题是:

经由基本流, 扩展流与异常流的组合, 所构成的业务场景切片, 是否就能形成 functional services 这类微服务的最佳边界上下文 (Bounded Context) ?

要能回答这个问题, 需先思考下面的六个问题:

1. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使开发人员与测试人员不易理解?

2. functional services 边界上下文 (Bounded Context) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 会产生过多的变更或缺陷, 而使得版本升级的速度与质量因此而下降?

3.  functional services 边界上下文 (BoundedContext) 内的业务场景切片是否过于庞大与复杂? 而使得在版本开发中, 此 functional services 已无法由单一的团队所完成?

4.  functional services 边界上下文 (BoundedContex