可落地的DDD(4)-如何利用DDD进行微服务的划分(2)

摘要

在前面一篇介绍了如何经过DDD的思想，来调整单体服务内的工程结构，为微服务的拆分作准备。同时介绍了咱们在进行微服务拆分的时候踩过的一些坑。
这篇介绍下咱们最终的方案，不必定对，欢迎留言讨论。

微服务划分

问题分析

上篇介绍过咱们一开始的服务划分标准

1. 一个领域一个服务的规则去拆分，
2. 同时为了保证领域的纯洁性，咱们区分了领域服务，和前台服务。领域服务就是领域逻辑，不直接对前端暴露。前台服务组装各个领域服务，暴露给前端。
3. 同时为了保持扩展，咱们预留了一个微服务做为服务孵化器。对于领域不清晰的（好比大部分的新的业务），放在这个服务里面孵化，而后等领域足够大的时候再拆分出去。

实践后有些典型的问题也比较突出

• 服务热点问题
  咱们是一个新的业务，在业务迭代的过程当中，大部分新需求都是领域不清晰，不知道能不能迭代下去的。因此按照以前的标准，都往growth服务里面去写代码，这样致使几乎团队里面的全部的人都在开发这一个项目，失去了拆分微服务的意义。

• 服务依赖太严重
  不管写什么需求，都须要写多个应用，领域服务1个，前台若是有pc,须要在pc服务上开发，移动端要展现，要在mobile服务开发。服务之间的调用须要写rpc client接口，须要发版本，由于同时开发的人多，常常发生版本混乱，依赖问题。服务上线也很头疼，改一个小需求，须要部署多个服务。微服务一个很重要的点是去耦合，可独立部署。多了一层UI层做为微服务显然不是很合适。

• 领域划分问题
  一个领域一个服务，粒度过小，有些东西不知道放在哪一个服务里面，好比用户收藏博客，是放在用户服务里面，仍是放在博客领域呢。

三个比较突出的问题，反应出的共性问题就是

• 服务边界不清晰

  微服务的边界不清晰，原由确定是标准定义的不够准确

• 服务之间依赖多了

  微服务的一个重要特征就是自治性，若是依赖的服务多了，那么咱们就享受不到微服务带来的好处，而只能感觉到微服务的坏处。

解决手法

为了解决以上问题，咱们反思了下咱们的划分标准，组内进行了深刻的讨论。一致以为是由于咱们为了推行DDD，在没有深刻思考的状况下，过早的进行了大面积的微服务拆分。致使了诸多的问题。虽然这么作在当时的状况下，是最优的解决方案，可是带来的问题也很突出。那何时才是进行微服务拆分的最好时机呢?
由于理论学习、认知始终都没有尽头，只有实践才能出真知。咱们没有纠结在过去的错误之中，而是从新读取了DDD的理论。这一次有了不同的思考。

DDD中有战略设计，划分领域，找出限界上下文，识别出核心域。而后有战术设计，对领域进行建模，
聚合根、实体、值对象、领域服务、领域事件等。战略设计一般就是指导思想，战术设计是具体打法。咱们一开始认定要
先有指导思想，而后再有具体打法。如今发现咱们错了，指导思想不是一蹴而就的，也不是不成不变的。在一开始没有标准时，它必需要来源于实际打法中。
同时须要在实践过程当中不断总结，修正、完善指导思想。

因而咱们又从新梳理了一遍咱们的总体业务

前台功能

把咱们全部端的前台功能都梳理一遍，画成图

业务架构全景

根据前台功能，进一步整理，抽象出业务架构全景

划分出上下文

根据业务架构全景，在核心域中创建出限界上下文，拆分微服务

很是抱歉了，涉及敏感信息，这里不能贴图,若是以为太抽象很差理解，请参考DDD落地：业务分析师和架构师的完美结对

新的微服务划分标准

咱们提出了一种新的微服务划分标准

• 肯定以限界上下文为微服务划分的标准

  限界上下文的划分很难，可是必需要作。限界上下文不是凭空造出来的，而是从一个实体关联关系、与业务人员沟通出来的。

• 服务的演进是以限界上下文做为单元进行演进的

  以前咱们拿一个微服务做为领域孵化器，其实就是放弃了对业务的总体认知，和对新需求的业务思考。
  咱们的新业务不是一个新产品，所有推倒重来的。大多时候它仍是解决某类业务上的问题。只是采起的手段不同罢了。
  因此咱们须要挖掘其本质，将它放到现有的上下文中。每一个上下文一个微服务，对应一个开发owner,他负责这个领域内的事情。
  这样每一个服务都有新的领域孵化。

举例

以电商举例，若是只是一个创业公司，不可能都跟阿里巴巴同样的架构，上百个服务。可是解决的问题电商领域能够抽象出来。

限界上下文

分为人、货、场、交易几个上下文。而后不断的孵化，哪一部分是你业务的核心域，而后不断的服务拆分，好比你也是一家作垂直电商的公司，这些基本的东西确定不该该是你的核心域，只能是支撑域，要否则你的业务确定发展不起来。

微服务的划分

从限界上下文中抽出微服务，一个微服务中包含了多个领域。

另外咱们遗弃了以前的UI服务，全部微服务能够直接和前台交互，这样能够有效的减小服务的依赖。
只有当须要多个领域进行组合时，咱们才写在一个新的【组合ui】服务里面

另外限界上下文不是一层不变的，好比商品营销，是一个领域，业务简单时和商品的关联性比较大，放在商品域。当你须要同时对店铺作营销，对用户作营销，显然他不该该在商品上下文了，那么能够剥离出来，做为一个独立的限界上下文：营销上下文。

相关阅读

可落地的DDD(1)-目标讨论

可落地的DDD的(2)-为何说MVC工程架构已通过时

可落地的DDD(3)-如何利用DDD进行微服务的划分

关注【方丈的寺院】，第一时间收到文章的更新，与方丈一块儿开始技术修行之路