在前面一篇介绍了如何通过DDD的思想,来调整单体服务内的工程结构,为微服务的拆分做准备。同时介绍了我们在进行微服务拆分的时候踩过的一些坑。 这篇介绍下我们最终的方案,不一定对,欢迎留言讨论。
上篇介绍过我们一开始的服务划分标准
实践后有些典型的问题也比较突出
三个比较突出的问题,反应出的共性问题就是
为了解决以上问题,我们反思了下我们的划分标准,组内进行了深入的讨论。一致觉得是因为我们为了推行DDD,在没有深入思考的情况下,过早的进行了大面积的微服务拆分。导致了诸多的问题。虽然这么做在当时的情况下,是最优的解决方案,但是带来的问题也很突出。那什么时候才是进行微服务拆分的最好时机呢? 因为理论学习、认知始终都没有尽头,只有实践才能出真知。我们没有纠结在过去的错误之中,而是重新读取了DDD的理论。这一次有了不一样的思考。
DDD中有战略设计,划分领域,找出限界上下文,识别出核心域。然后有战术设计,对领域进行建模, 聚合根、实体、值对象、领域服务、领域事件等。战略设计通常就是指导思想,战术设计是具体打法。我们一开始认定要 先有指导思想,然后再有具体打法。现在发现我们错了,指导思想不是一蹴而就的,也不是不成不变的。在一开始没有标准时,它必须要来源于实际打法中。 同时需要在实践过程中不断总结,修正、完善指导思想。
于是我们又重新梳理了一遍我们的整体业务
把我们所有端的前台功能都梳理一遍,画成图
根据前台功能,进一步整理,抽象出业务架构全景
根据业务架构全景,在核心域中建立出限界上下文,拆分微服务
非常抱歉了,涉及敏感信息,这里不能贴图,如果觉得太抽象不好理解,请参考DDD落地:业务分析师和架构师的完美结对
我们提出了一种新的微服务划分标准
以电商举例,如果只是一个创业公司,不可能都跟阿里巴巴一样的架构,上百个服务。但是解决的问题电商领域可以抽象出来。
分为人、货、场、交易几个上下文。然后不断的孵化,哪一部分是你业务的核心域,然后不断的服务拆分,比如你也是一家做垂直电商的公司,这些基本的东西肯定不应该是你的核心域,只能是支撑域,要不然你的业务肯定发展不起来。
从限界上下文中抽出微服务,一个微服务中包含了多个领域。
另外我们遗弃了之前的UI服务,所有微服务可以直接和前台交互,这样可以有效的减少服务的依赖。 只有当需要多个领域进行组合时,我们才写在一个新的【组合ui】服务里面
另外限界上下文不是一层不变的,比如商品营销,是一个领域,业务简单时和商品的关联性比较大,放在商品域。当你需要同时对店铺做营销,对用户做营销,显然他不应该在商品上下文了,那么可以剥离出来,作为一个独立的限界上下文:营销上下文。
相关阅读
可落地的DDD(1)-目标讨论
可落地的DDD的(2)-为什么说MVC工程架构已经过时
可落地的DDD(3)-如何利用DDD进行微服务的划分
关注【方丈的寺院】,第一时间收到文章的更新,与方丈一起开始技术修行之路