canonical

   業務架構平臺的設計與實現要比普通業務系統困難很多。一個核心難點在于如何建立普遍有效的應用程序模型，如何控制各種偶然性的業務需求對系統整體架構的沖擊。大多數現有的業務架構平臺都是提供了一個龐大的萬能性產品，它預料到了所有可能在業務系統開發中出現的可能性，并提供了相應的處理手段。業務系統開發人員的能力被限定在業務架構平臺所允許的范圍之內。如果業務架構平臺的復雜度為A+，則我們最多只能用它來開發復雜度為A的業務系統。一個典型的特征就是使用業務架構平臺的功能配置非常簡單，但是要開發相應的功能特性則非常困難，而且必須采用與業務系統開發完全不同的技術手段和開發方式。
   采用業務架構平臺來開發業務系統，即使看似開發工作量小，最終產生的各類配置代碼量也可能會大大超過普通手工編程產生的代碼量，這意味著平臺封裝了業務內在的復雜性，還是意味著平臺引入了不必要的復雜性？很多業務架構平臺的賣點都是零代碼的應用開發，低水平的開發人員也可以主導的開發，但是為什么高水平的程序員不能借助于這些開發平臺極大的提高生產率？
   一般的業務架構平臺無法回答以下問題：
1) 業務系統可以通過使用設計工具來重用業務架構平臺已經實現的功能，但是業務系統內部大量相似的模型配置如何才能夠被重用？
2) 特定的業務領域中存在著大量特殊的業務規則，例如“審批串行進行，每一步都允許回退到上一步，而且允許選擇跳轉到任意后一步”。這些規則如何才能夠被引入設計工具，簡化配置過程？
3) 已經開發好的業務系統作為產品來銷售的時候，如何應對具體客戶的定制化？如果按照客戶要求修改配置，則以后業務系統自身是否還能夠實現版本升級？
  
   Witrix平臺提供的基本開發模型為
          App = Biz aop-extends Generator<DSL>
在這一圖景下，我們就可以回答以上三個問題：
1) 業務模型通過領域特定語言(DSL)來表達，因此可以使用語言中通用的繼承或者組件抽象機制來實現模型重用。
2) 推理機對于所有推理規則一視同仁，特殊的業務規則與通用的業務規則一樣都可以參與推理過程，并且一般情況下特殊的業務規則更能夠大幅簡化系統實現結構。
3) 相對于原始模型的修改被獨立出來，然后應用面向切面(AOP)技術將這些特定代碼織入到原始模型中。原始模型與差異修改相互分離，因此原始模型可以隨時升級。

  Witrix平臺所強調的不是強大的功能，而是一切表象之后的數學規律。Witrix平臺通過少數基本原理的反復應用來構造軟件系統，它本身就是采用平臺技術構造的產物。我們用復雜度為A的工具制造復雜度為A+的產品，然后進一步以這個復雜度為A+的產品為工具來構造復雜度為A++的產品。