canonical

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

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