关于业务代码扩展点保留的想法

一般的业务代码流程，无外乎新的功能，从头开始，还有一种就是在原有的基础上进行添加，实际的代码编写也一般是 参数校验，业务流程实际处理，最后返回。

在业务流程的代码里，如果迭代比较频繁，里面的代码会越来越多，越来越长，可读性也会越来越差，同时在后面的迭代过程中，后来的人，对这块东西的理解成本也会越来越高。到最后，就成了谁也不敢碰，谁也不敢动的庞然大物了。

但是，其实跳出来看，一个业务流程，本身的业务逻学习成本其实还是比较好的，主要是涉及到了很多的相关逻辑，然后在编写的过程中，容易彼此杂糅，互相耦合，我们开发的项目里，长的方法很多，但是里面最可怕的，其实是各种所谓的Map，很多，而且看着看着，就不知道这里面放的是什么业务对象，然后又得回去找，同时还得留意这个东西哪里在用，什么逻辑会改动里面的数据。这种读起来就很头疼。

还有订单流程，订单的新建，无非就是，拿到平台的数据，然后新建记录就可以了，但是这个过程中，还杂糅着日志，库存，拆合单，订单状态更新，还有涉及三方仓的，很容易就晕头转向了，这个时候，这个流程里面需要添加一点功能，那真的，理解成本是比较高的，你不知道，改了这里其他地方会不会有影响，或者这一大片代码里面，本身是不是就留着一些隐藏的问题，还有隐藏的逻辑。

所以，每个业务逻辑，在开发或者重构之初，需要留好扩展点，需要将基础业务剥离出来，比如拆分订单，我就是对订单进行拆分订单，然后就完事了，至于其他关联的逻辑，通过扩展点实现，后续的迭代，如果是涉及基础的业务，直接在基础的业务逻辑进行处理，如果和基础业务无关，直接在扩展点里面进行处理。当然，这里有个问题就是，扩展点会很多，相关业务会很多，同时相关业务本身也要留足够的扩展点，可读性也会降低，但是还是稍微优雅一点。维护成本也会稍微低一点。分

参照切面的逻辑，扩展点的保留，其实也是比较容易理解的。无非就是，业务执行前，业务执行中，业务执行后，业务异常。所有的业务逻辑（比较主要的业务逻辑），都会有这样的流程，而先相关的业务流程的触发，也无非就是，在这几个过程中进行的。当然这里面，还会涉及到，事务，同步，异步的问题。