事務指令碼與領域建模

目前項目架構的兩類常用方式，就是事務指令碼和領域建模。

 

事務指令碼，其實並沒有架構，只是利用了已有的成熟技術平台提供的天然架構，又或者說像.net,j2ee等天然提供了事務指令碼及其實現的環境。

事務指令碼，就是直接直接開發sql及gui，在gui或公用類中通過sql直接操作資料庫。

領域建模，就是提高領域層設計，將持久儲存層局限在一部分必須儲存的資料，同時支援gui的替換和擴充。領域建模或者說是OO帶來的產物。如果以此來看，那麼事務指令碼更傾向於基於OO技術架構的面向過程開發。而領域建模則更好的利用了OO的思想。

對於事務指令碼，雖說有面向過程之“嫌疑”，但是在某些情境下是不可缺少的，比如對資料庫操作的效能要求比較高，或者客戶需要的資料與資料庫比較近或者資料比較大，那麼在架構設計中，有必要拉近GUI和DB的距離，sql語句天然與DB比較近，尤其在一些報表統計的需求中。

所以sql server提出了olap/reporting service技術，這就是從資料庫層面來挖掘建模的空間，讓資料庫層尤其是OLAP能夠做更多的事情，來彌補領域邏輯層的低效率。

目前OLAP/DATA WAREHOUSE技術發展迅速，這也主要是基於面對大資料時資料統計中領域建模的弱點而提出的。

 

還有一個模式叫做“表模組”，這應該是對資料庫表進行強命名的做法，例如使用OleDb，以及一個強型別的DataSet來對資料庫表做CRUD處理。這種思路，除了在一些特殊的情境下需要使用外，一般來講這種思路已很少使用。

 

如果OODB出來以後，事務指令碼將不會再使用了，但是表模組將會以一種新的形勢出現，或許能夠代替當前的事務指令碼，而在一些小型的應用中“死灰複燃”。

OODB出現之後，相當於將ORM在DB層做了實現，當然也增加了緩衝，提升了存取效率。同時在領域建模過程中也省卻基於關係型資料庫的考慮。同時領域建模將包括OODB的設計。

而目前的開發還是基於關係型資料庫，所以在做領域建模後，會面臨將持久對象寫入資料庫的需要，在領域模型和關係型資料庫之間，需要使用ORM。而在我的一個架構中，我還加入了Convertor層來處理領域模型與關聯式模式/持久類對象之間的相互轉換。真的是相當麻煩。因為目前ORM的持久類設計是受到限制的，是難以完全融入領域建模之中的。