微服划分的各种姿势

微服务是一种理念，没有确切的定义和边界，好比设计原则，是属于抽象的概念。在定义不明确的情况下谈划分也是一种各说各话，具体问题需要具体分析，所以这里谈到的划分不是绝对标准，有人说微服务不难，难的是服务的划分，从侧面也反应了划分具有一定的困难。这里的矛盾在于粒度，如果粒度太大了，分和不分似乎都差不多；如果粒度太小了，聚合、一致性，发布、调用链、调试等都是坑。这里罗列了三种常见拆分姿势，每个人的的经验和视野不同，划分的结果也会有不同，因此需要一种通用的科学的方法。

思考：为什么很多企业没用DDD，划分的微服务也大差不差，有的用了，效果也并不理想？

康威定律：组织形式等同系统设计

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

以业务逻辑为关键因素
考虑业务模块的稳定性和可靠性、功能的独立性、可扩展性
强调拆分应该是多选，而不是单选。具体情况具体分析，可以自由灵活排列组合。

微服务的划分方法（1）

微服务设计主要有两种方法：以流程为切入点的领域驱动设计方法和以数据为切入点的数据驱动设计方法。领域驱动设计方法是自上而下的架构设计方法，通过通用语言不断交流，确定关键业务场景来确定边界上下文和寻找聚合根。数据驱动设计方法是自下而上的架构设计方法，强调数据结构，通过分析需求，确定整体数据结构，据此来作服务划分。

自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。由于这种策略不必受限于现有系统，你可以用 DDD 领域逐级分解的领域建模方法。从下面这张图我们可以看出它的主要步骤：第一步是将领域分解为子域，子域可以分为核心域、通用域和支撑域；第二步是对子域建模，划分领域边界，建立领域模型和限界上下文；第三步则是根据限界上下文进行微服务设计。

自底向上的策略适用于遗留系统业务模型的演进式重构。下面我以互联网电商和传统核心应用的几个典型业务域为例，带你了解具体如何采用自底向上的策略来构建中台业务模型，主要分为这样三个步骤。第一步：锁定系统所在业务域，构建领域模型。锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型。例如可选取传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来完成领域建模。