區分DDD中的Domain, Subdomain, Bounded Context, Problem/Solution Space
譯自: Domain, Subdomain, Bounded Context, Problem/Solution Space in DDD: Clearly Defined
領域驅動設設計是一種設計系統的方式，強調在領域專家和系統建造者之間建立一個通用的語言。著名的DDD原則包括：使用通用語言和確定隱性和顯性。
DDD中的有些概念並沒有明確的定義，且高度隱晦。每個人對域(Domain), 子域(Subdomain), 問題空間(Problem Space)和解決空間(Solution space)都有不同的理解。本文將會對這些概念進行澄清。
本文基於GitHub上的一個會話，參與會話的很多人都來自DDD社群。
模糊但沒有歧義
在開始定義術語之前，我想強調Kenny Baas-Schwegler 提出的一個重要觀點。他強調DDD應該是模糊的。由於DDD的模糊性，我們可以用它來探索、建模和解決新問題(現有的DDD模式和準則並沒有限制我們的思維方式)。
模糊性意味著可以用一個詞來描述在某些方面相似但並不相同的不同事物。例如"few"，在一些場景下，它表示的範圍可能是2-3，而在其他場景下可能表示不同的範圍， 如5-10。關於模糊性最主要的是可以通過上下文進行推斷(如果不同的人以截然不同的方式解釋它，那就太模稜兩可了)。
如果我說出一個詞，期望對方能給出相同的定義，但對方實際上理解的是另一種定義，則說明沒有對齊定義(即我們認為正在討論同一件事，但實際上並不是)。
使用DDD時，我們希望擁抱模糊性，但同時也希望對每個概念的模糊程度有共同的理解。
以下的定義都比較模糊，但當我們使用這些詞時，能夠對齊對它們的認知。
Domains
DDD對領域的定義與劍橋字典中的定義非常類似：
上面對領域的定義非常模糊。什麼是一個感興趣的領域？有可能是任何事情。一個領域實際上是圍繞某些概念的子集的任意邊界。
How to group these concepts into domains?
如果使用彩色形狀來表示概念，那麼應該如何對它們進行領域劃分？如你所想，實際存在很多劃分的方式。
我們可以把方形放到方形領域，那圓形放到圓形領域。但藍色方形和藍色圓形也可以歸屬為藍色領域。
The same concepts can belong to different domains
當對系統進行建模時，我們可以選擇最合適的領域邊界來使得軟體和組織邊界保持一致。即使我們選擇按照顏色來對齊領域，但形狀領域仍然存在。
在我參與的每個建模領域以及每個建模研討中，不同的人都傾向於跨不同領域邊界來分割系統。這是正常的，應該根據實際情況擁抱模糊性，並運用設計思維。
Subdomains
域和子域有什麼區別？這個問題比較簡單，子域並不是字典中的一個單詞(domain存在於字典中，但subdomain不存在...)。子域在web世界中佔有重要的位置，但在DDD中意味著什麼？
在DDD中，一個子域是一個相對的概念。域和子域可以互動使用。當我們使用子域時，我們強調將該域作為另一個已經確定的更高階域的"孩子"。
因此，每個子域也是一個域，且大部分域都是子域。當我們的模型不包含更高階別的父域時，才不會將一個域認為是子域。
Core, Generic, Supporting (Sub)Domains
當聽到一個核心域實際是一個子域時，很多人通常會感到困惑。在Eric Evans 的書中，他將領域稱為核心域，但有時也會稱之為子域。
你可以將域和子域認為是DDD中的模糊性之一，子域同時也是域，使用核心域還是子域並不重要，它們在概念上是模糊的，但並沒有歧義。
核心域聽起來更好，而核心子域則強調它屬於一個更高階別的域。
Problem Space vs Solution Space: 更好的DDD模型
讓人最困惑的是問題空間和解決空間。每個人對DDD上下文中的問題空間和解決空間都有不同的看法
我認為使用問題/解決空間模型太過簡單，無法完整地傳達DDD所要表達的內容，Simon Wardley的戰略圓形則更加形象。
Simon Wardley’s Strategy Cycle
在上圖中有如下元素：
- Purpose：我們關心的領域中存在哪些問題需要解決或需要達到什麼目的？
- Landscape：我們關心的領域的當前狀態是什麼？
- Climate：領域的推動力是什麼？我們該如何演進？
- Doctrine：我們應該普及的好的做法。
- Leadership：在現有和新領域中我們應該做出什麼樣的方案或變動。
Domains/Subdomains Problem 還是Solution Space?
除非我們可以明確定義問題或解決空間，否則無法對該問題做出回答。
當前的系統中包含(子)域，而(子)域中存在又會存在使用者需求和相關問題。對這些需求和問題的解決會涉及多個(子)域，並會修改(包含子域的)系統狀態。因此邏輯上所有的空間都會包含(子)域。
那麼在決定為哪個子域設計解決方案時，是否存在僅存在於問題空間的子域？這樣，一些域只需要與解決相關，而與問題無關。
從下圖的例子中可以看到，是可以將一些子域作為單一的問題空間或解決空間，但沒有必要這麼做，應該採用更確切的方式對業務進行劃分。
My understanding of problem and solution space in DDD. There are many other definitions out there.
新的解決方案也會帶來新的問題，或正如Simon Wardley所說：高階系統創造了新的價值來源。
我建議儘量避免使用問題空間，而應該準確地指出你所要表達的內容：purpose, landscape, climate, doctrine, leadership等。
無論何時，當用到術語"問題空間"和"解決空間"時，都需要闡明你所講的觀點。你的問題空間也是別人的解決空間，只是看的角度不同而已。
在作者的理解中，問題空間就是針對使用者來說，存在問題的地方；而解決空間就是針對提供解決方案的人來說，落地方案的地方。問題空間和解決空間只是不同人的不同視角而已。
領域是分層的
如果一個域可以包含子域，而子域又可以作為一個域，那麼子域就可以包含更多細粒度的子域。域和子域是層級概念。
當設計社會技術系統時，通常我們會希望將域放到不同層級。一個組織的領導者可能會希望看到公司的7個頂級域。軟體架構師可能會希望看到100個微服務的領域邊界。
企業架構中會在不同層級用到業務能力的概念。業務能力可以看作是域或子域
Domains are hierarchical and they represent business capabilities
Subdomain vs Bounded Context
這是DDD中另一組可能讓人混淆的概念，但如果明確瞭解了子域的定義，就非常容易解釋。
我們已經得出，子域是一個非互斥的，任意概念的集合。而一個邊界上下文是一個模型的邊界，代表了模型的概念，關係和規則。相同的子域可能由無數模型構成。
DDD中的模型的表達方式多種多樣，如便籤或程式碼，以及任何展示領域概念，關係和規則的事物。
由於一個邊界上下文是一個模型的邊界，它可能包含來自多個子域的概念(如跨多領域的規則)，或者可以將單個子域建模為多個邊界上下文(如子域中的各個邏輯處理單元)。
Subdomains vs Bounded Contexts: Areas of the domain vs boundaries of models of the domain