知道这些坑，你还敢乱把单体架构拆成分布式吗？( 三 ) 一、背景我们在聊架构风格之

这一步是相对简单的，我们梳理出库存面向服务的业务方进行服务划分。这部分无需进行太多代码的改造，一套接口通过变更不同的group别名，部署到不同的集群即可。

文章图片
拆分后，不同的服务应对不同的业务方，系统错误的隔离性好，不会说出现一损俱损的局面，稳定性上也有了保障。在解决了稳定性的问题后，留给我们了一些喘气的间隔，可以有时间去进行代码的优化。因为刚才也提到了，我们只是通过分布式的集群部署来解决容错性的问题，但是代码还是一套，臃肿的代码也会拖慢我们的开发上线速度。那么接下来要进行的就是，对业务代码的解耦，这块也是难度最高的。我们是如何做的呢？
2）业务拆分
业务拆分的思路是什么呢？以业务本身为导向，充分了解系统业务模型，划分业务边界业务依赖的范围，细分功能，尽量减少功能之间的重复依赖根据拆分功能的影响大小进行评估，拆小保大拆分的过程中不要修改业务逻辑，不要进行拆分之外的任何优化动作（除非是bug）
基于上述拆分的思路，库存系统又是如何划分的业务模块呢？动了哪些代码？
3）如何划分业务模块
关于业务划分，网上有很多方法论，事件风暴法、四色建模法等等，但是万法不离其宗，那就是围绕事件。以库存系统举例：库存初始化（门店+sku库存创建）、库存数量维护（修改现货数量、修改可售状态）、扣减业务（购物车扣减、提单扣减、订单取消扣减）、提醒业务（缺货提醒）等。每一个事件都有独立的链路轴，以及时间线可以形成闭环。

文章图片

文章图片

文章图片
4）如何在原有模块上拆分
大多数单体架构都是面向过程的设计， domain层充斥这个各种DTO、VO、BO ，所以在层与层的数据交互过程中，大都是经历了多次的POJO 。另外就是service层充斥着和DAO层数据交互以及参杂了业务，而且严重违反了依赖倒置原则，整个层变得非常的沉重。这里举个例子：同层级间相互引用service层包含了太多业务逻辑，无法保障原子性

文章图片
这里截取部分代码片段作为案例，来讲述下我们在拆分业务的过程中，需要做一些什么操作。对service层进行CQS的拆分把业务逻辑从原有的service层抽离，保障service方法遵循SRP原则。新增业务聚合层（或者向六边形架构里提到的adapter转接口）来聚合service层的方法

文章图片
①原始代码
@Service
publicclassSkuMainServiceImplimplementsSkuMainService{
privatestaticfinalorg.slf4j.LoggerLOGGER=LoggerFactory.getLogger(SkuMainServiceImpl.class);
@Resource
privateSkuMainDaoskuMainDao;
@Resource
privateZkConfManagerCenterServicezkConfManagerCenterService;
@Resource
privateProductImagesServiceproductImagesService;//同级互相引用，未遵循依赖倒置
@Resource
privateMqServicemqServiceImpl;
@Value("${system.group.environment}")
privateStringsystemGroupEnvironment;
/**
*问题：service层聚合了太多业务逻辑倒置上层方法没办法统一
*@paramskuMainInfoMQEntity