[Domain Driven Design] 第二步：Bounded Contexts 和其應用
在定義出領域模型和通用語言後，下一步便是定義Bounded Contexts 和這些 Bounded Contexts 之間的關係。
Domain Driven Design 的設計重點圍繞在Bounded Contexts，和其在系統設計上的做法和應用。在近年來的 Micro-service Architecture 的風潮下，越來越多人將 DDD 的 Bounded Contexts 作為定義各個服務的系統設計單元。也讓 DDD 在軟體架構設計上逐漸成為主流。
In Domain Driven Design, a Context is defined as:
“The setting in which a word or a statement appears that determines its meaning”
根據通用語言所定義出的商業領域模型 (Problem Space)，Bounded Contexts 的目標是劃分出在軟體 (Solution Space) 上找到合適的界線將商業領域模型進行適當的分割。每個Bounded Context 應該有清楚的功能上的定義，而且你所用來定義每個 Bounded Context 的詞彙應盡可能地與領域模型所用的詞彙相吻合。如果在同一個(domain) 領域中同一個詞有著不同的定義時，你可能在這個領域中便會需要多個 Bounded Context。下面用幾個例子，來說明幾個在定義Bounded Contexts時，所可能遇到的狀況。
№1: 同一領域詞彙，不同意義
以下圖為例，Customer 在Support Context和Sales Context 中，可以代表不同的意義，在產品支援的領域來看，你的銷售代表或是終端顧客都可以是產品支援的顧客；而在銷售的領域來說，顧客的意義就不一樣了。在軟體架構設計時，應該要利用在前文所提到的領域模型，Conceptual Models，和通用語言，去做出Bounded Contexts 之間界線的判斷。
№2: 同一領域詞彙與意義，但不同使用案例
相較於之前的例子，在系統設計時，很多時候因為你的領域專家使用了相同的詞彙來描述不同的使用案例，很容易會將不同的概念放在同一個Bounded Context中，進而實作時放在同一個系統和資料庫中。
以下圖為例，Banking Account 可代表存款戶頭，也可代表你在報銷時，所連結的銀行帳戶。在報銷的領域中，系統所需知道的是系統須匯款到哪一個戶頭；而在存款的領域中，存款餘額和存提款的明細是其系統的責任，而存款系統並不需要知道任何報銷系統的資訊。若沒有清楚的定義出使用案例和了解各個詞彙在不同使用案例所代表的意義，在此例中，很容易地會把報銷和存款領域合併，而讓 Banking…
