什么是DDD分層架構

本篇內容介紹了“什么是DDD分層架構”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

DDD（Domain DrivenDesign，領域驅動設計）作為一種軟件開發方法，它可以幫助我們設計高質量的軟件模型。在正確實現的情況下，我們通過DDD完成的設計恰恰就是軟件的工作方式。 UL（Ubiquitous Language，通用語言）是團隊共享的語言，是DDD中最具威力的特性之一。不管你在團隊中的角色如何，只要你是團隊的一員，你都將使用UL。由于UL的重要性，所以需要讓每個概念在各自的上下文中是清晰無歧義的，于是DDD在戰略設計上提出了模式BC（BoundedContext，限界上下文）。UL和BC同時構成了DDD的兩大支柱，并且它們是相輔相成的，即UL都有其確定的上下文含義，而BC中的每個概念都有唯一的含義。 一個業務領域劃分成若干個BC，它們之間通過Context Map進行集成。BC是一個顯式的邊界，領域模型便存在于這個邊界之內。領域模型是關于某個特定業務領域的軟件模型。通常，領域模型通過對象模型來實現，這些對象同時包含了數據和行為，并且表達了準確的業務含義。 從廣義上來講，領域即是一個組織所做的事情以及其中所包含的一切，表示整個業務系統。由于“領域模型”包含了“領域”這個詞，我們可能會認為應該為整個業務系統創建一個單一的、內聚的和全功能式的模型。然而，這并不是我們使用DDD的目標。正好相反，領域模型存在于BC內。 模式一：四層架構

Eric Evans在《領域驅動設計－軟件核心復雜性應對之道》這本書中提出了傳統的四層架構模式，如下圖所示： User Interface為用戶界面層（或表示層），負責向用戶顯示信息和解釋用戶命令。這里指的用戶可以是另一個計算機系統，不一定是使用用戶界面的人。 Application為應用層，定義軟件要完成的任務，并且指揮表達領域概念的對象來解決問題。這一層所負責的工作對業務來說意義重大，也是與其它系統的應用層進行交互的必要渠道。應用層要盡量簡單，不包含業務規則或者知識，而只為下一層中的領域對象協調任務，分配工作，使它們互相協作。它沒有反映業務情況的狀態，但是卻可以具有另外一種狀態，為用戶或程序顯示某個任務的進度。 Domain為領域層（或模型層），負責表達業務概念，業務狀態信息以及業務規則。盡管保存業務狀態的技術細節是由基礎設施層實現的，但是反映業務情況的狀態是由本層控制并且使用的。領域層是業務軟件的核心，領域模型位于這一層。 Infrastructure層為基礎實施層，向其他層提供通用的技術能力：為應用層傳遞消息，為領域層提供持久化機制，為用戶界面層繪制屏幕組件，等等。基礎設施層還能夠通過架構框架來支持四個層次間的交互模式。傳統的四層架構都是 限定型松散分層架構 ，即Infrastructure層的任意上層都可以訪問該層（“L”型），而其它層遵守 嚴格分層架構

User Interface層主要是Restful消息處理，配置文件解析，等等。 Application層主要是多進程管理及調度，多線程管理及調度，多協程調度和狀態機管理，等等。 Domain層主要是領域模型的實現，包括領域對象的確立，這些對象的生命周期管理及關系，領域服務的定義，領域事件的發布，等等。 Infrastructure層主要是業務平臺，編程框架，第三方庫的封裝，基礎算法，等等。

“什么是DDD分層架構”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！