业务系统高层设计思路——以CRM为例

  业务系统建立之初，一般会对基础架构进行选型，整合若干个业界常用的框架后，系统便能够在一段时期内，较为快速地支撑一些业务场景，见下图。

  随着需求不断新增和变化，业务场景变多，变复杂。在现有框架难以支撑其需求逻辑的情况下，业务代码的冗余操作会越来越多，最终导致开发效率和质量的双下降，见下图。

  因此，投入一定资源长期地去维护、更新框架，保持框架活力，能起到事半功倍的效果。所谓的框架，不仅限于缓存中间件、数据库中间件、网络传输组件等开源软件，也包括能解决实际业务问题的自研框架。
  这里说的实际业务问题，不仅仅是那些需求内容，当系统升级到一定规模，就会出现一些非功能性的痛点，而且随着时间推移，痛点会转化为系统发展的瓶颈，接下来以CRM为例，具体说明。

1、规则框架，业界更多称为规则引擎

  CRM系统可以说遍地都是规则。一旦选择把规则“翻译”到代码里，代码就是上帝。程序员就多了一项工作，把代码“翻译”回规则以便客户了解。这种“翻译”工作是纯人工的，容易失真、缺失甚至发生错误，最终系统升级就错上加错。因此规则的不可见性成为痛点，也就需要有对应的框架去解决，较为有名的是开源的drools（另一篇《drools的懒加载和执行》有分享简单实践），难度再高一点的，有用antlr来构建规则语言，后面我会另起一篇来分享个人实践。

2、配置框架

  规则一多，为简化调整工作，少改点代码，配置应运而生。出于便捷性、友好性、可操作性、版本管理等等方面的考虑，业务系统可以配套引入或开发一些配置界面，然后后端轻量化地实现配置刷新，版本管理等等。

3、任务框架

  支持任务动态加载与调整，与服务一样需要弹性伸缩，相应的任务执行情况可视化。

  上文提到的几点，虽然重点在描述框架，但业务代码也同等重要。我个人是比较赞同敏捷软件开发提到的原则——“最好的架构，需求，和设计出自于自我组织管理的团队”，每一位开发都要有义务和能力参与到编写框架和业务代码的工作中，业务代码产生价值，框架服务于业务代码。两者在物理上是分包隔离的，但在使用场景上又是连续的。因此没有跑题哈，还是从系统整体来描述设计思路。