可视化设计
可视化设计
业务可视化和可配置化
好的领域建模可以降低应用的复杂性,而可视化和可配置化主要是帮助大家(主要是非技术人员,比如产品,业务和客户)直观地了解系统和配置系统。要注意的是可视化和可配置化难免会给系统增加额外的复杂度,必须慎之又慎,最好是能使可视化和配置化的逻辑与业务逻辑尽量少的耦合,否则破坏了原有的架构,把事情搞的更复杂就得不偿失了。
我们将领域的行为(也叫能力)和扩展点用可视化的方式呈现出来,并对于一些不需要编码实现的扩展点用配置的方式去完成呢。比如还是转账的例子,对于透支策略 OverdraftPolicy 这个业务扩展点,新来一个业务说透支额度不能超过 1000,我们可以完全结合规则引擎进行配置化完成,而不需要编码。
通过 Annotation 注解的方式对领域能力和扩展点进行标注,然后在系统 bootstrap 阶段,通过代码扫描的方式,将这些能力点和扩展点收集起来上传到中心服务器,然后再通过 GUI 的方式呈现出来,从而做到业务的可视化和可配置化。大概的示意图如下:
这里要分清楚两个概念,业务逻辑流和工作流,很多同学混淆了这两个概念。业务逻辑流是响应一次用户请求的业务处理过程,其本身就是业务逻辑,对其编排和可视化的意义并不是很大,无外乎只是把代码逻辑可视化了。而工作流是指完成一项任务所需要不同节点的连接,节点主要分为自动节点和人工节点,其中每个人工节点都需要用户的参与,也就是响应一次用户的请求,比如审批流程中的经理审批节点,CRM 销售过程的业务员的处理节点等等。此时可以考虑使用工作流引擎,特别是当你的系统需要让用户自定义流程的时候,那就不得不使用可视化和可配置的工作流引擎了,除此之外,最好不要自找麻烦。
扩展点设计
身份识别
业务身份识别在我们的应用中非常重要,因为我们的 CRM 系统要服务不同的业务方,而且每个业务方又有多个租户。比如中供销售,中供拍档,中供商家都是不同的业务方,而拍档下的每个公司,中供商家下的每个供应商又是不同的租户。所以传统的基于多租户(TenantId)的业务身份识别还不能满足我们的要求,于是在此基础上我们又引入了业务码(BizCode)来标识业务。所以我们的业务身份实际上是(BizCode,TenantId)二元组。在每一个业务身份下面,又可以有多个扩展点(ExtensionPoint),所以一个扩展点实现(Extension)实际上是一个三维空间中的向量。我给它起了个名字叫扩展坐标,这个坐标可以用(ExtensionPoint,BizCode,TenantId)来唯一标识。
扩展点机制
扩展点的设计是这样的,所有的扩展点(ExtensionPoint)必须通过接口申明,扩展实现(Extension)是通过 Annotation 的方式标注的,Extension 里面使用 BizCode 和 TenantId 两个属性用来标识身份,框架的 Bootstrap 类会在 Spring 启动的时候做类扫描,进行 Extension 注册,在 Runtime 的时候,通过 TenantContext 来选择要使用的 Extension。TenantContext 是通过 Interceptor 在调用业务逻辑之前进行初始化的。整个过程如下图所示: