開發背景
全世界的程序員都將減少代碼量提高代碼複用率作爲奮鬥目標。爲此作出了很多努力，函數封裝、面向對象、AOP、設計模式等等。這些努力極大的削減了代碼的重複。但是在編程世界中我們任然存在着這樣的一種代碼：他們是不同的，但是他們很相似。最爲典型的例子就是我們爲JavaBean編寫的getter和setter方法。想像一下如果沒有IDE的幫助，對有100個（這不是誇張，銀行系統中很常見）屬性的Bean寫getter和setter。那將是多麼痛苦的事情。所以代碼生成技術是解決此類問題的一個很好的高效的手段。但代碼生成技術有自己的侷限性，這是顯而易見的——它只能基於某種規律來產生代碼。這種規律我斗膽命名爲“代碼模式”。於是代碼生成技術就是將需要收集的元數據（如JavaBean的屬性）和代碼模式融合起來經過計算生成成品代碼。
元數據 + 代碼模式 = 成品代碼
現實世界中代碼生成技術到處應用Eclipse、PowerDesigner、MyGeneration等等都獲多或少的集成了代碼生成技術在自己的產品中，但這些產品的共同的特點是模式過小或不利於更加智能的模式定製。比如:在一個BS構架的系統中我們要完成一個實體的CRUD功能，我們首先要定義實體屬性，在定義完了所有實體的屬性後，我們調用MyEclipse生成geter/sertter方法,然後我們編寫DAO的接口，儘管這些DAO都非常形似。寫完接口後我們寫DAO的實現層。我們再次調用MyEclipse的Override/Impment Method將接口中的所有方法簽名複製到實現層中來。然後再補充實現邏輯，且這些實現邏輯與其他實體也是類似的。Service層需要同樣操作。在寫完真個實體的功能我們需多次調用代碼生成命令，且大部分代碼都很類似。代碼模式過小造成我們無法在人機交互界面調用一個命令來完成所有的工作。代碼模式不利於定製讓我們依然避免不了寫相似但不同的代碼。
爲此公司開發了基於BS構架的代碼生成器、提供可可以配置DAO\Service\Action\JSP\JS等等各層代碼模式的地方。且一鍵可生成多層代碼。
但BS構架的代碼生成工具亦缺點。比較明顯的是元數據的提供要求開發人員面向表設計而不是面向領域模型設計；不能將生成的代碼卸載；DDL的生成基於特定數據庫其他數據庫不支持；無法提供像IDE一樣方面的元數據錄入的交互界面；生成代碼後要手工調用IDE完成編譯功能；支持的模式不夠智能；等等。
由於各企業基本都有自己的一套技術平臺、開發規範，我們可以從中抽象出具體的代碼模式。然後依據此代碼模式結合領域模型啓動開發的思想。提供一套較爲方便直觀的元數據錄入界面。最終完成代碼生成。
實現目標
基於領域模型驅動開發的思想，提供一套較爲方面直觀的元數據錄入人機交互界面，
提供可插拔的代碼模式定製機制，完成代碼生成。