单块系统分解小结

单块系统把全部不相关的代码放在一块儿，修改一行代码没法保证对其余部分形成影响。并且为了发布一个小的功能须要整个系统从新部署。

1.     识别系统中的高层限界上下文，好比业务边界。

2.     建立包结构来表示这些上下文，把代码移动到相应的位置

3.     分析包之间的依赖。代码之间的依赖关系应该跟组织（好比按照业务区分包结构，组织应该是业务）中不一样部分的实际交互方式一致。若是不一致分析为何这样并解决。

4.     增量改造单块系统

5.     边界肯定，代码也分离完成，接下来须要抽取某个包中的所有代码，建立单独系统，抽取哪一个部分要考虑得到的收益是否最大。收益能够考虑以下几个因素：

改变速度：后期可能对某个方面进行大量修改，若是抽取出来做为一个服务的，使其成为一个自治的单元，对后期的开发速度将大大加快

团队结构：交付团队分布在两个不一样地区，谁维护的分离给谁

安全：某个服务拥有敏感信息，须要作更加严密的保护，若是把这个服务分离出去能够对这个单独的服务作监控。传输数据的保护和静态数据的保护

技术：特定的服务须要特定的技术，好比其余语言，可以大大改善咱们的服务，那么能够分离出去做为一个单独的服务

6.     抽取出来的服务应该尽可能少地被其余组件所依赖

7.     对dao层进行划分，把数据库映射相关的代码和功能代码放在同一个上下文中

8.     不一样模块提供API方式进行数据访问，不能经过数据库集成方式。而后去除数据库外键关联约束，经过代码来实现这个约束。

9.     共享静态资源的处理：

            a 每一个包复制一份该表的内容，将来每一个服务也会保存这样一份副本，若是增长一个属性，后期维护困难

            b 共享静态数据放入代码，好比属性文件，枚举类，也会出现a中的问题，不过操做简单的多

            c 做为单独服务，若是值得咱们这么作的话能够考虑

10.  共享数据的处理：共享数据意味着一个表被多个模块共享，读写数据。领域概念不是在代码汇总进行建模，相反是在数据库中隐式建模。共享数据表多是咱们缺失的领域概念，意味着共享数据表能够具象话，做为一个新的包，最终能够获得一个清晰的客户服务

11.  共享表的处理：因为两种实体字段相似，最初处于方便把他们放在了同一个地方，即比较通用的行条目表。当把代码所有放在一块儿时，事实上很难意识到咱们把不一样的关注点放在了一块儿。解决方案就是按照两种实体分红两个表。

12.  先分离数据库结构后分离服务。好处在于能够随时选择回退这些修改或是继续作，而不影响服务的任何消费者。咱们队数据库分离感到满意以后，就能够考虑对整个应用程序的分离了。

13.  事务处理：分离服务后两个写操做可能不在一个事务里，解决一致性方案有：

        a 最终一致性 ：第一个写成功后，第二个写操做能够放入队列、日志文件中，或者其余方式，以后尝试对其进行处罚，确保在将来的某个时间达到一致

        b 拒绝整个操做：第二个操做失败后发起一个补偿事务来抵消以前的操做，好比一个DELETE操做把以前的操做记录删除，而后向用户报告该操做失败了

        c 分布式事务：横跨多个事务，而后使用一个叫作事务管理器的工具来统一编配其余底层系统中运行的事务。这里的事务会运行在不一样系统的不一样进程汇总，一般他们之间使用网络进行通讯。经常使用的算法是两阶段提交

参考《微服务设计》