好的领域建模可以降低应用的复杂性，而可视化和可配置化是帮助大家更为直观的了解系统和作配置系统的。
比如现在的低代码或无代码方式，其实就是考虑到了不同目标用户对于系统模型的了解和配置的需求。
业务可视化，业务配置化也是很多SaaS软件的卖点。
但需要注意的是，不要为了可视化而可视化，不要为了配置化而配置化，好的可视化和配置化应该是建立在良好的建模基础上的。
配置化和可视化，不可避免会给系统设计带来额外的复杂度。配置化能力、可视化能力、领域内核，这三者一定要隔离开，不要产生耦合，因为这本身就是三件事，没必要放在一起。
如果做不好三者的解耦，强制把三件事放在一起，就把原本简单的事情搞复杂了。
在BDF中，对于系统可扩展的实现，借鉴了业界普遍的做法，就是业务身份和扩展点定义，以支撑不同业务差异化的需求。
在此基础上，我们结合TOGAF思想，把能力也可视化出来，结合低代码或其他配置化能力，可以低成本的对这些抽象出来，并且被可视化出来的能力做配置化。
能力的定义，我们参照了DDD中的一些概念定义，约定于一个领域行为。
将行为和规则在架构上剥离开（行为是主干，规则是小细节），不同能力主干及能力的扩展，都有自己的小细节，骨干行为和规则配置可以隶属于两套系统，即运行域和配置域。
我个人其实是不喜欢规则引擎的，因为他会让你看不到流程细节（代码看到一半需要去看规则引擎的代码片段），让思维跳入跳出。
所以骨干行为和规则策略如何更好的集合，边界如何划分，如何降低这种跳入跳出的心智负担，是架构师需要考虑的，而不是简单直接的引入一个所谓的规则引擎就万事大吉了。
简单来说，规则引擎就是降低了编码成本，但不应该成为理解业务流程全局的难点。
在BDF中，我们采用了一种低入侵的方式，就是java的注解，注解起到定义能力和扩展点的作用，但不会让你忽略整体细节。
在编译、部署阶段，通过代码扫描的方式，将能力点和扩展点信息收集起来，上传到中心服务，以可视化的方式展示出来，进而做到了业务的可视化和配置化。
通过注解 AOP的能力，将外部规则引擎的规则引入，实现了全局不混乱，小细节（主要是代码片段）有可自迭代的效果。
这里也会引入一个新的思考点，就是哪些需要被可视化出来？这个边界和原则是什么？
要回答这个问题，就需要分清，什么是业务逻辑，什么是工作流。
业务逻辑可以认为是响应一次用户请求的批处理过程，本身具备业务逻辑概念，但这部分被可视化或编排起来的意义不大（这里要用目标导向，就是你可视化的目的是什么？想给谁看？看了之后想起到什么作用？）。
业务逻辑的可视化，无外乎是代码逻辑的可视化。话说，产品或业务关心你的业务逻辑，他真的需要看代码吗？或者说，想了解业务逻辑的玩法，看代码是最好的方式吗？
所以，我觉得把代码逻辑这部分可视化出来的意义不大，因为看得懂代码的只有技术同学，技术同学又不需要废这么大劲以这种方式看代码逻辑，通过IDE看代码不香吗？
真正的有可视化价值的是反映业务流程的，他的目标用户首要肯定不是研发，而是产品或者业务。
工作流可视化的价值在于，可以通过一种宏观或者微观的角度了解业务全貌，对于流程中的一些关键环节的关键规则有知晓即可。简单来说，就是想了解业务，仅仅到了解，能支撑他决策和思考即可，写代码这事最终还是研发的工作，产品或者业务不关心。
这里就是我上面说，我反对很多规则引擎的原因之一，就是大量的代码逻辑细节被可视化出来了，美其名曰流程可编排（明显是为了可视化而可视化），但对于业务和产品来说价值不大，对于研发来说，反而增加了成本，多了很多跳入跳出的心智负担，把简单事情复杂化了。
真正好的可视化是反应业务流程的，比如审批流，你的不同审批流程（请假、休假、报销、专利等）他的全貌是不一样的，每个节点应该是谁，这个节点审批是关注什么信息，对你（业务）来说非常重要，而不是那些处理细节或者代码逻辑。这才有可视化和流程配置化的空间，因为他解决了业务复杂背后的不确定性。
