4、傳統三層架構與DDD分層架構
模型是抽象的
現實是形象的
技巧是重要的
思想是永恆的
從傳統三層架構與DDD分層架構的編程演變其實是思想的演變。
傳統三層架構，即用戶界面層UI、業務邏輯層BAL、數據訪問層DAL。一般同時還有建立一個Model實體類的工程項目。DDD分層架構，即表現層UI、應用層Application、領域驅動層Doman、基礎設施層Infrastructure。
傳統三層架構，我一直使用、結構單一、邏輯也清晰，三層各處理各自的事務，上層向下層引用接口與方法，下層向上層提供接口服務，各層之間調度方法時可能通過Model傳值，也可以返回值Model。但以往，我處理的業務邏輯層中，基本上都是將DAL層的接口值返回給業務邏輯層，然后BLL層再將結果返回給UI層，BLL層只做了上傳下達的作用，其它的作用發揮得較少。以往三層架構中的重點是BLL層。當我需要新增業務功能時，或者需要CRUD操作，需要將UI層、BLL層、DAL層都需要增加類文件以達到處理CRUD操作的功能。當然，傳統三層架構中，也會引入一個新的Common工程或Utility工程，為BLL、DAL、UI提供共用或通用方法或行為的支持。若是有需要對第三方軟件或系統提供數據接口，這時，可以將接口作為IIS站點或WebService 或WebAPI提供，此時這個接口可以放在UI供第三方調用。
DDD分層架構，是從傳三層架構中演變過來的。它將傳統的三層架構做了一定的變更，將四個層中的內容做了重新歸內，並對分層結構的業務重點作了分配。UI層還是UI層、應用層用於調度第三方的應用接口、以及提供口服務給第三方，同時將在應用層增加Dto工程項目用於操作應用層與UI層的數據傳遞即值對象傳遞以及Dto與Model實體類之間的映射，將傳統的BLL層、Model層歸納到領域驅動層Domain中，同時將倉儲的接口層放在Domain層中，將傳統的DAL層實現以及通用的Common層或Utility層歸納到基礎設施層Infrastructure中。
從傳統三層架構（包括Common公共層、Model實體層）演變到DDD領域驅動模型設計的分層架構，從項目歸納上比較，可能多了DAL接口層即倉儲接口層，其它的工程項目只是做了位置上的遷移。同時傳統BLL層的命名變理為Service，同時在應用層增加了Dto工程項目。
從這種演變上可以看出，進一步將層與層之間的耦合減低、將Dto（數據傳輸層-值對象）引入，給表現層提供了更多的數據展示的靈活性。更多演變的體驗，后續文章再敘述。
解決方案結構命名可參考http://www.cnblogs.com/lori/p/3345590.html
http://www.cnblogs.com/daxnet/archive/2010/07/07/1772584.html
http://www.cnblogs.com/daxnet/archive/2011/05/10/2042095.html