實施DDD閱讀-策略設計

1. 概念篇

1.1 領域

　　廣義上講，領域便是一個組織所作的事情以及其中所包含的一切，也是組織的業務範圍以及在其中所進行的活動。軟件所討論的領域便是這個組織的領域，應該是清晰明確的。不一樣的層面或粒度，領域一詞承載的內容不一樣。爲了簡化問題，避免大泥團這樣的架構出現，咱們認爲領域拆分是必要的，能夠幫咱們簡化問題域，是有好處的。領域不是領域模型。好比電子商務系統中電子商務是咱們的領域。

1.2 子域

　　子域是領域的一部分，領域能夠劃分爲若干個小的邏輯獨立子域，從而更好的應對問題的複雜性。子域包括核心子域、支撐子域和通用子域三種類型。子域並不必定要作的很大，子域能夠只包含一套算法，只要是獨立的、內聚的。在DDD實施時這種簡單的子域能夠稱爲一個獨立的模塊，從核心子域中劃分出來，更容易重用及維護。好比電子商務系統中包含訂單子域、產品目錄子域、發票子域、庫存子域、物流子域。

1.2.1 核心子域

　　核心子域是整個業務領域的核心，是企業業務核心競爭優點，也能夠是業務成功的關鍵因素。好比電子商務系統，訂單子域就是核心子域，是整個業務的關鍵所在。

1.2.2 支撐子域

　　支撐子域關注業務的非核心方面，它對應的限界上下文能夠經過建立或購買來支撐咱們的業務。好比電子商務系統中發票子域、物流子域即是支撐子域。

1.2.3 通用子域

　　若是一個子域被整個業務系統所使用，那麼它就是通用子域。好比電子商務系統中庫存子域。

1.3 限界上下文

　　限界上下文指業務語言層面的上下文邊界，它是顯示的、是充滿業務語義的。在一個好的限界上下文中，每個術語應該只表示一個領域概念，無歧義且惟一。一個限界上下文並不必定包含在一個子域中，一個子域也能夠包含多個上下文。對於一個領域中的限界上下文不是孤立存在的，是經過多個限界上下文的協做完成業務。對於限界上下文的識別是關注點分離的明確表象，它能夠隔離其它不相關業務、減小干擾噪音，識別隱藏的領域概念。同一個物件在不一樣上下文中的領域概念是不一樣的，這些易於混淆的領域概念是理解限界上下文的關鍵。好比庫存，在倉庫中無人購買的庫存稱爲積壓件；已經被訂購即將發貨的庫存稱爲即將發送件；被損壞的庫存稱爲無用件。在庫存的不一樣上下文中須要區別對待。

1.4 問題空間

　　問題空間是領域的一部分，問題空間中考慮的是當前業務所面臨的挑戰，如庫存系統的成本較高問題。對於問題空間的開發將產生新的核心子域，問題空間的子域隨着項目的不一樣而不一樣，關注着各自不一樣的業務問題。在咱們完成問題空間分析時，咱們須要對其進行評估，須要與業務人員（客戶）一塊兒確認咱們對問題空間的核心子域以及要達成的業務目標的理解，其中包含哪些核心概念，它的支撐子域和通用子域是什麼，從而確認相關利益方在目標上達成一致，也便是咱們一般在項目啓動時所講的構建業務願景。

1.5 解決方案空間

　　解決方案空間討論的是如何用軟件來解決這些業務挑戰，它包括一個或多個限界上下文，是一組特定的軟件模型。限界上下文在這裏有更多的闡釋，限界上下文便是一個特定的解決方案，劃分限界上下文每每也意味着對於解決問題空間的分析映射和實現。解決方案空間一般會收到現有系統和技術的影響，須要考慮是否重用，資源時間的約束，如何集成，風險控制等。在解決方案空間中，限界上下文是重要的建模工具。

2. 上下文是王道

　　限界上下文組成解決方案。咱們在實施DDD戰略設計的時候，應該是從問題空間出發，確認解決方案空間，劃分限界上下文，從而識別其中的核心領域模型；並經過問題空間的更新和解決方案的更新/正實時的調整模型及其關係。上下文的劃分由問題空間和它要達成的業務目標所決定，與組織文化相關，與stakeholder相關。同一個術語在不一樣的企業組織、不一樣的業務範疇它表明的領域概念是不一樣的，這也是可行的，只要在組織內團隊內達成一致。

2.1 限界上下文不僅是領域模型

　　1）領域模型是限界上下文中的主要公民，當前的上下文決定了它所表明的惟一的、具體的業務術語或概念。每一個領域模型具備本身的屬性和操做，領域模型之間互相交互完成限界上下文的業務。內聚的領域模型是一個好的限界上下文的重要組成。

　　2）但限界上下文並不只是領域模型，它同時也包含了那些爲領域模型提供交互手段和輔助功能的內容，好比數據庫Schema設計等。但如何確認領域模型/組件/服務在上下文的邊界內是一個須要解決的問題。

2.2 限界上下文的大小

　　限界上下文的粒度須要適中。限界上下文須要足夠大，以可以表達它所對應的整套通用語言。限界上下文須要清楚包含的核心領域概念，清楚那些不屬於通用語言的外部概念。上下文映射能夠幫助咱們作出相對正確的判斷。限界上下文也須要足夠小，從而使得它所封裝的通用語言和領域對象具備清晰的定義，但也不要基於約束它的範圍。限界上下文能夠經過分析，由上而下，大粒度到小粒度逐漸分解，直至團隊達成一致。

2.3 幾點注意

　　限界上下文首先考慮的必定是領域問題、通用術語。 * 避免從技術層面考慮限界上下文，技術組件不能定義限界上下文。 * 避免以開發任務的分配來拆分限界上下文，這些可能致使錯誤的上下文建模方式。 一個能夠幫助劃分限界上下文或者子域的方法是假設這部分從第三方購買，從而思考所帶來的變化和合適的劃分。

3. 上下文映射

　　上下文映射關注於解決方案空間中限界上下文之間的集成關係，能夠幫助界定和劃分與其餘系統/模塊之間的依賴關係，識別交付風險（如集成瓶頸、組織管理問題等）及其須要應對的方案。

Eric Evans 在DDD種定義了九種產品和組織的集成關係。

3.1 集成關係

　　協做關係
　　共享內核
　　客戶方和供應方開發
　　遵奉者
　　防腐層(ACL)
　　開放主機服務(OHS)
　　發佈語言(PL)
　　另謀他路
　　大泥球
　　繪製上下文映射圖時須要首先定義上下文之間的集成關係和集成方式，是基於協做的，仍是客戶供應關係的。在SaaSovation的例子中，用戶身份與訪問上下文與協做上下文是客戶和供應方的關係，身份是協做的上游，提供主機服務；而協做是身份的下游，消費身份提供的服務，並採用防腐層保證內部的穩定性。

4.總結

　　兩個概念：子域與限界上下文。
　　1）子域是指組織內所作事情的一個獨立的部分；子域不會隨着系統的替換而發生變化，不管解決方案是什麼，咱們的問題空間仍然存在。

　　2）限界上下文是解決問題中的一個獨立的具備一組清晰的經過術語的範疇，限界上下文能夠跨子域，能夠是已有系統，是模塊。

　　一種思考方式：假設替換法
　　在討論解決方案空間的概念時常常能夠採用的一種思考方式是假設替換法，若是這個限界上下文被替換會出現什麼變化？