canonical

   业务架构平台的设计与实现要比普通业务系统困难很多。一个核心难点在于如何建立普遍有效的应用程序模型，如何控制各种偶然性的业务需求对系统整体架构的冲击。大多数现有的业务架构平台都是提供了一个庞大的万能性产品，它预料到了所有可能在业务系统开发中出现的可能性，并提供了相应的处理手段。业务系统开发人员的能力被限定在业务架构平台所允许的范围之内。如果业务架构平台的复杂度为A+，则我们最多只能用它来开发复杂度为A的业务系统。一个典型的特征就是使用业务架构平台的功能配置非常简单，但是要开发相应的功能特性则非常困难，而且必须采用与业务系统开发完全不同的技术手段和开发方式。
   采用业务架构平台来开发业务系统，即使看似开发工作量小，最终产生的各类配置代码量也可能会大大超过普通手工编程产生的代码量，这意味着平台封装了业务内在的复杂性，还是意味着平台引入了不必要的复杂性？很多业务架构平台的卖点都是零代码的应用开发，低水平的开发人员也可以主导的开发，但是为什么高水平的程序员不能借助于这些开发平台极大的提高生产率？
   一般的业务架构平台无法回答以下问题：
1) 业务系统可以通过使用设计工具来重用业务架构平台已经实现的功能，但是业务系统内部大量相似的模型配置如何才能够被重用？
2) 特定的业务领域中存在着大量特殊的业务规则，例如“审批串行进行，每一步都允许回退到上一步，而且允许选择跳转到任意后一步”。这些规则如何才能够被引入设计工具，简化配置过程？
3) 已经开发好的业务系统作为产品来销售的时候，如何应对具体客户的定制化？如果按照客户要求修改配置，则以后业务系统自身是否还能够实现版本升级？
  
   Witrix平台提供的基本开发模型为
          App = Biz aop-extends Generator<DSL>
在这一图景下，我们就可以回答以上三个问题：
1) 业务模型通过领域特定语言(DSL)来表达，因此可以使用语言中通用的继承或者组件抽象机制来实现模型重用。
2) 推理机对于所有推理规则一视同仁，特殊的业务规则与通用的业务规则一样都可以参与推理过程，并且一般情况下特殊的业务规则更能够大幅简化系统实现结构。
3) 相对于原始模型的修改被独立出来，然后应用面向切面(AOP)技术将这些特定代码织入到原始模型中。原始模型与差异修改相互分离，因此原始模型可以随时升级。

  Witrix平台所强调的不是强大的功能，而是一切表象之后的数学规律。Witrix平台通过少数基本原理的反复应用来构造软件系统，它本身就是采用平台技术构造的产物。我们用复杂度为A的工具制造复杂度为A+的产品，然后进一步以这个复杂度为A+的产品为工具来构造复杂度为A++的产品。