概述:
架構是高層的設計,若是設計和理解有誤,必將在實現時帶來各類問題。架構又是最穩定的,不會由於各類具體技術的依賴,如各類UI框架、ORM框架、IoC框架的更新換代而受到影響。
上文的總結沒有任何Demo是由於架構更偏向於設計層面,有從設計視圖建立解決方案經驗的人,一看就知道我在說什麼。本文將展現從架構設計視圖到.NET多項目解決方案的過程。主要包含如下內容:
(1)演示DDD分層架構到.NET多項目解決方案的映射。
(2)演示DDD分層依賴到.NET項目引用的映射。
(3)演示依賴注入在.NET多項目解決方案中的使用。
1、原始的DDD分層
1.架構圖
2.搭建解決方案
新建空白解決方案,添加以下項目:
(1)DDD.Domain類庫項目。
(2)DDD.Application類庫項目。
(3)DDD.Infrastructure類庫項目。
(4)DDD.UI.MVC ASP.NET 空項目,選中MVC引用。
(5)DDD.Repository類庫項目。
3.設置項目間的引用關係:
(1)DDD.UI.MVC添加DDD.Application、DDD.Domain、DDD.Infrastructure和DDD.Repository的引用。
(2)向DDD.Application添加DDD.Domain、DDD.Infrastructure引用。
(3)向DDD.Domain添加DDD.Infrastructure引用。
(4)向Repository項目添加DDD.Domain和DDD.Infrastructure引用。
4.使用依賴注入:
爲了更完全的解耦,咱們即便對依賴注入的實現也應用依賴倒置原則,咱們不依賴任何具體的IoC框架及其種類和版本。在基礎設施層中使用2種不一樣的IoC框架實現了該接口,而且在使用時展現了經過直接注入和經過反射兩種方式。經過反射能夠將IoC的實現依賴使用配置文件管理。
(1)IoC抽象接口
(2)管理類
(3)管理依賴注入
5.代碼圖和解決方案視圖:
代碼圖赤裸裸的告訴咱們三個字「不和諧」:
(1)看起來更像以基礎設施層爲核心。
(2)Repository沒法置於基礎設施層,即便你將它的命名空間改成DDD.Infrastructure.Repository也沒有用。
(3)領域層對外有依賴。
(4)看了架構圖誰能跟這代碼圖對應上?
2、改善的DDD分層
1.架構圖
2.搭建解決方案
新建空白解決方案,添加以下項目:
(1)DDD.Domain類庫項目。
(2)DDD.Application類庫項目。
(3)DDD.Infrastructure類庫項目。
(4)DDD.UI.MVC ASP.NET 空項目,選中MVC引用。
3.設置項目間的引用關係:
(1)DDD.UI.MVC添加DDD.Application、DDD.Domain和DDD.Infrastructure的引用。
(2)向DDD.Application添加DDD.Domain、DDD.Infrastructure引用。
(3)向DDD.Infrastructure添加DDD.Domain引用。
4.改善:
(1)IEntity和IRepository接口定義在領域層,領域層再也不依賴基礎設施層。
(2)Repository真正在基礎設施層實現。
5.代碼圖和解決方案視圖:
看起來很不錯:
(1)和架構圖完美對應。
(2)領域層爲中心。
(3)不再用爲基礎設施層沒法引用領域層而在服務層添加沒必要要的代碼了。
3、最新的DDD分層
1.架構圖
2.搭建解決方案:
同上
3.設置項目間的引用關係:
(1)DDD.UI.MVC添加DDD.Application、DDD.Domain和DDD.Infrastructure的引用。
(2)向DDD.Application添加DDD.Domain引用。
(3)向DDD.Infrastructure添加DDD.Application和DDD.Domain引用。
4.改進:
(1)將IService接口定義在應用層。
(2)進一步將全部依賴的接口定義在領域層和應用層,包括依賴注入管理。
5.代碼圖和解決方案視圖:
更好理解和使用:
(1)在架構級別,以領域爲核心,將其餘技術依賴抹平到一個實現層次,寫代碼不再用擔憂不知道往哪寫了。
(2)將領域邏輯和應用邏輯扔到應用層和領域層,全部依賴扔到實現層,架構圖就是解決方案視圖。
(3)在三種解決方案中,依賴最少,依賴方向一致,最易理解和使用。