目的
- 减少复杂的业务， 限制业务边界
- 定制化容易操作 和 定制化 可以基于版本的基线
- 监控各个端口， API 影响是可控的
- 水平扩展
- 测试方便
标准指标
- 服务是自治的
- 服务的范围不大不小
- 服务接口是幂等
- 独立开发， 独立部署
- 服务接口无状态性
- 各部分数据做到最终一致性
具体步骤和里程碑
- （must） 认证服务器需要提前
- （must） 前后端代码进行分离
- （must） 负载均衡 session 需要外部处理
- （must） 后端代码模块直接切分
- （must） 各个模块直接的耦合， 尽量使用异步的方式进行沟通
- （must） 引入 界限上下文 的概念， 让每个模块都控制在一定的范围内
- （must） 服务注册和发现
- （must） UnitTest 的引入
- 每个模块独立的数据库
- 规范到每个模块的负责人
- （must） 开发时候 每个模块的管理 和 部署
- 优化每个模块， 引入 读写模型 的 分离
- 监控不同的模块
步骤的分解
（must） 认证服务器需要提前
需要在 nginx 后进行 CAS 的验证， 并且验证的信息是会放在session 里面的？ 这个的话， 好像有点问题， 因为session 已经是放在 缓存进行保存了， 需要咨询 劲飞。已经咨询过劲飞了， 可能验证的模块是当做是公用的模块， 同时 Session 是做到无状态， 下次做灰度测试的时候就会比较方便。 但是需要同时考虑到微信， 手机登录等各种操作， 做到统一性。
（must） 前后端代码进行分离
需要做到前后端人员能够快速进行开发。另外一个问题： 如何做到前端都可以做到分到模块来进行限制呢？
（must） 负载均衡 session 需要外部处理
直接调整 nginx 配置， 直接共享Session
（must） 后端代码模块直接切割
重中之重， 先拿一个 Customer 的模块 （这个模块选的有点大， 但是在实践过程中， 不断的缩小模块的范围， 让服务的切割， 不大不小， 刚好满足服务的界限， 而且考虑到人员的维护性； 或者拿 Customer 评价 这个模块） 进行验证。 这个涉及到下面的几个方面
**短期目标： **
- 直接拆分模块， 把 Customer 的模块 代码都独立出来， 依赖于原系统
- 对于 Customer 的模块， 对外围引用的模块， 界限上下文 必须要清晰， 分清晰 CoreDomain 和 辅助类型的Domain， 辅助类型的Domain 没有独立的表， 仅仅是 利用接口 获取到 的 ValueObject
- 对于 其他引用到 Customer模块的， 引入 因为 customer Domain 引发的 辅助型的 Domain， 没有独立的表， 仅仅是一个 ValueObject， 其他模块不能 直接import Customer 模块的类
- 还是使用原来的获取接口（直接调用方法）
- 模块分出来后， 就进行自己的版本基线控制
短期目标 具体步骤目标[http://www.jianshu.com/p/6b4ddd8b3bfb]
**中期目标： **
- 接口使用到 RPC 的方式来做到， 获取到 的 ValueObject
- 分离公用的第三方的库， 让 Customer模块 依赖于公用的库
- 分割模块后， 读取数据 和 业务 之间的区别？
- 如果读取是多个表的数据的话， 应该是如何去处理
- 业务 和 门面模式控制的业务， 应该是如何去分开
最终目标：
- 直接拆分模块， 把 Customer 的模块 代码都独立出来， 只依赖于公用类库
- 对于 Customer 的模块， 对外围引用的模块， 界限上下文 必须要清晰， 引入辅助类型的Domain， 辅助类型的Domain会有自己存储结构。
- 对于 其他引用到 Customer模块的， 引入 因为 customer Domain 引发的 辅助型的 Domain
- 使用到 异步更新 和 订阅消息的方式来更新
（must） 各个模块实现弱耦合， 尽量使用异步的方式进行
- 正常的业务流程， 使用 队列的方式进行交互
- 辅助性Domain属性的更新， 使用到 订阅者方式进行更新
- CoreDomain的属性的更新， 如果是其他模块引起的， 都是需要订阅者方式进行更新
这需要等 前面的 代码模块的切割 才可以比较好的实现。
（must） 引入 界限上下文 的概念， 让每个模块都控制在一定的范围内
（must） 服务注册和发现
使用 SpringBoot 和 ZooKeeper 的方式来做到服务的注册和管理
（must） UnitTest 的引入
对单独的模块可以进行 UnitTest 的验证， 做到每个模块快速进行自动化测试
每个模块独立的数据存储模块
有可能不同的模块是 使用不同的数据库等。
规范到每个模块的负责人
人员只负责自己的模块， 看不到别人的模块， 就可以限制出错的范围， 每次修改都是有信心的。
（must） 开发时候 每个模块的管理 和 部署
后端代码模块直接切割 短期目标 后
依赖项目， 还是整一个 War 的进行部署
后端代码模块直接切割 长期目标 后
利用到 Spring 和 ZooKeeper， 分离的方式进行部署
