业务重构

在重构一个结构繁杂，代码逻辑千丝万缕的业务系统时，除了对代码层面的重构之外，很多人会忽视对于业务结构的重构和简化。

目前正在遭遇着这个事情，一个异常复杂的系统，不断的在上面添加需求，代码量增大，函数的体积也在增长，Web服务也越来越臃肿。关于代码层面的解耦，方法论很多，但本质上就是“提取公因式”，即相同的代码不要写两遍。通常，良好模块的模块设计，很容易达成这种只写一次的目标。

还有的复杂度就是模块之间的依赖和调用，很多人就会想到，用消息队列去解耦。其实消息队列解耦只是在技术层面，把两个东西物理上分开了，逻辑上还是要靠消息去驱动，复杂点就变成了何时发消息，发怎么样的消息。过于复杂的依赖和调用，在修改的时候，容易出现纰漏，比如漏发了某个消息。

其实我想说的不是技术层面的简化，而是业务层面的简化。业务人员首先要扪心自问一下，业务真的有必要设计的那么复杂吗？真的需要吗？如果你觉得需要的话，那你再想一遍，真的需要吗？

有一些业务人员过度设计，复杂设计，盲目设计，本来简单的一个业务规则，硬是要设计成很复杂的规则，设计出很复杂的一个功能，但是该功能的使用率很低，但是对于这个功能的维护成本又很大，一不小心出的bug就是由它产生。

理论上，业务设计和程序设计并没有区别，无非一个是用自然语言描述，一个用代码表述。业务设计也是可以画出流程图，状态图的。但是，如果一个业务设计天生就复杂，那么指望代码层面上很简洁，很清晰，无异于痴人说梦。

某种程度上说，业务的重构解耦，比代码层面的重构解耦更有意义。好的业务设计人员，应梳理出各个业务需求，尽量设计出相互独立的业务，封装不变的业务模块，把恶心的，易变的业务需求单独切割，尽量不要影响成熟业务模块的功能。