可视化设计

业务可视化和可配置化

好的领域建模可以降低应用的复杂性，而可视化和可配置化主要是帮助大家（主要是非技术人员，比如产品，业务和客户）直观地了解系统和配置系统。要注意的是可视化和可配置化难免会给系统增加额外的复杂度，必须慎之又慎，最好是能使可视化和配置化的逻辑与业务逻辑尽量少的耦合，否则破坏了原有的架构，把事情搞的更复杂就得不偿失了。

我们将领域的行为（也叫能力）和扩展点用可视化的方式呈现出来，并对于一些不需要编码实现的扩展点用配置的方式去完成呢。比如还是转账的例子，对于透支策略 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 在调用业务逻辑之前进行初始化的。整个过程如下图所示：