再谈垂直和水平切分

本篇为在应用集中化背景下，数据库集群本身的垂直和水平切分方法的点滴思考。



首先我们看应用的垂直切分，应用本身包括了两大类型的应用，一种是以核心数据为中心的应用，一种是以纯粹的流程工单为核心的应用。前者如资产管理，主数据管理等相关应用；后者如运维工单管理，OA办公管理等应用。对于工单型应用各种工单流程之间相互耦合性非常底，共享的基础数据也相当少，因此这类应用相当容易进行垂直切分，而且切分的也相当干净；而对于资产管理这类应用， 在进行垂直切分的时候必须考虑到有一个比较厚的基础数据支撑的底层，然后才是业务流程场景拆分的各个关键业务模块。

对于基础数据支撑的底层，为了保证整个领域数据模型的全局和完整性，而适合再进行复杂的垂直切分操作；这个底层在建立的时候必须有领域模型的系统分析和设计思想，在整个底层领域模型上建立领域服务层，如上篇文章所谈到的领域对象服务，领域业务服务，领域组合服务三种类型；注意这种拆分后还有一个关键点， 即对于底层上方的各个业务模块和底层基础数据模块间无论是直接数据库DAL连接，还是共享服务的方式，都是一种紧耦合的关系，脱离了底层基础数据，上面的业务模块本身无意义。

上层的业务模块本身对底层有大量的对象或数据级的CRUD和访问操作，个人建议还是务必考虑走轻量的接口服务模式和集成模式，减少不必要的性能损耗。 我们一直谈对于系统内部的SOA服务化是否彻底的问题，在整个服务化架构设计上也不适合走极端，影响到整个业务系统的性能。对于跨业务系统的场景，对于底层数据支撑则必须要通过共享服务的方式进行调用，但是在这种场景下要注意到更多的是调用轻量数据传送的领域业务服务，而不是大量的领域对象服务。因此对于跨应用场景下底层能力走共享ESB业务服务模式是成立的。

在SOA参考架构和业务组件化下，更多强调的是业务组件本身朝外部提供业务服务能力，业务组件间的相互调用必须走业务组件提供的业务服务，即业务组件横向之间彻底解耦。但是对于单个应用模块而言，其展现和应用层到底层业务组件间是更多强调的是业务逻辑层API能力的梳理和定义， 这些API业务能力在纵向调用时候完全可以走轻量的API，只有在跨业务组件调用的时候才需要通过代理对外发布为轻量的业务服务。

或者可以简单的说，对于分模块开发而言更加强调的是各个模块直接的相互解耦和隔离，强调模块间的接口以及由接口识别出来的业务服务； 对于领域驱动架构设计下的开发，则首先强调的是可以分层开发，再强调分层后的模块进一步细分，这种分层开发即完全可以是一个开发商来做共享的领域服务层；而另外一个开发商来做前端的展现层和应用层；做前端应用层的开发商完全依赖于前者所提供出来的领域服务层能力，而不在关注底层数据库设计和底层数据库选择等内容。

这个思考清楚了即回答一个问题，即在首先进行垂直切分的思考模式下，对于模块内上层和底层直接的服务调用和交互我们不太关心；而更加关心的是跨模块间的业务服务交互和调用。在这种模式下可能并不存在共性的领域服务模型层。

因此对于以数据为核心的应用系统，可以首先考虑水平拆分的问题，在水平拆分后仍然按照DDD的核心思想来建立共享的领域服务层，再对上层的应用功能模块进行垂直拆分。在这种模式下达到领域对象层的完整能力没有丝毫被拆解或破坏。但是在这种拆分模式下必须考虑扩容的问题，即对于跨各个水平拆分的业务流协同和共享的问题。垂直拆分下我们更多考虑的是跨业务模块的协同和共享；而水平拆分下则更多考虑的是跨地域，业务组织单位下的协同和共享； 可以说水平拆分更加类似于一个集团型企业内部的支撑多组织的SaaS应用，只是需要考虑集团到下属子公司，子公司到各个分支机构的业务协同问题。

对于以流程为中心的业务应用，建议的方式是直接进行细粒度的垂直切分，不用太考虑水平拆分的问题；而这种模式下的扩容只是模块的进一步垂直切割；对于以数据为中心的业务应用，则建议首先考虑水平拆分，保留领域服务层的完整能力，在进行上层应用模块的垂直切分。

不论是哪种场景，实际的建议还是尽量少进行垂直+水平模式的混合切分，在这种混合切分场景下将极大的增加应用设计和开发的复杂度，加大对事务一致性控制的难度。数据虽然比较容易的达到的分布式水平扩展的需求，但是应用开发复杂度和业务一致性的要求却大大降低，往往得不偿失。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密