限界上下文（BC）是什麼

翻譯自 DDD - The Bounded Context Explained,有整理

你問的限界上下文（BC）是什麼？

「特定模型的分隔適用性。限界上下文使團隊成員可以清楚地分享對必須一致的內容以及能夠獨立開發的內容。」

看定義看懂了嗎？

• BC是最難解釋的DDD原則之一，但它多是最重要的，由於沒有BC就不能作DDD。所以，您必須瞭解如何在實際獲取根聚合，聚合，實體和值對象以前識別BC。
• 讓咱們再試一次：上下文意味着具體的責任。限界上下文意味着責任是經過明確的邊界來強制執行的

舉個例子

過程

• 約翰，X公司的開發人員。約翰在IT部門工做
• 麗塔，她是同一家公司的會計師。麗塔在會計部門工做
• 此時，IT部門是一個限界上下文，會計部門是另外一個限界上下文
• IT部門有責任處理公司中與IT相關的全部事務，而會計部門處理與會計相關的全部事務
• 約翰不會進入麗塔的辦公室並修改工資單，而麗塔也不會去約翰的辦公室並修改他的代碼。
• 雖然他們能夠這麼作，但這將是一個醜聞。由於若是他們這樣作，他們將超越他們的界限。
• 若是麗塔在會計軟件（內部開發）中發現錯誤，她會致電IT部門處理。她不會啓動Visual Studio並開始搞亂代碼。這既不是她的責任同時她也不須要知道怎麼作，即便她知道VS是約翰用來編寫代碼的程序（事實上，VS在會計師的計算機上將是一個很是奇怪的軟件）
• 一樣明智的是，工資單文件或發票在IT部門中是沒有位置的。
• 固然，當約翰遇到涉及工資單的問題時，他要求麗塔調查一下。
• 二者都尊重彼此的界限，並根據本身的責任行事。
• 但IT部門自己分爲兩組：軟件開發組和管理組。第一組實現功能並修復錯誤。第二組處理服務器。每一個組也是有限的上下文。他們有本身的責任和明確的界限。 DBA不編寫C＃代碼，約翰不會破壞服務器配置。每一個人都按照本身的責任行事並在本身的範圍內行事。

二者都有很是精確的責任，他們的界限很是明確。

小結

因此，IT部門是BC。約翰是其模型的一部分。
事實上，全部有意義的東西（開發人員，服務器等）都是BC的一部分，它應該在內部保持一致（開發人員應該編寫軟件而不是詢問發票）。
這意味着麗塔在IT方面沒有地位，她不該該處理與IT相關的任何事情。
麗塔是會計BC的一部分。她可能正在訪問IT辦公室，但她只是一個匆匆過客，她對該部門毫無心義，沒有人但願她編寫代碼或充當開發人員。約翰可能喜歡麗塔，並花了一些時間在她的辦公室，但這並不能使約翰成爲一名會計師。

不一樣BC之間的「合做」

BC與BC的關係

咱們能夠看到，在必定程度上，BC是自治的，它們不重疊。此外，若是來自一個BC（X）的對象轉到其餘BC（Y），它並不意味着它如今是後者的一部分，它僅被視爲一個對Y沒有意義的簡單對象。因此它們幾乎是獨立的，那麼他們如何一塊兒工做？

不一樣BC之間該如何合做

例子說明

• 登場新人物 -> 安德魯(IT部門經理)

按照例子來講，當會計部門必須和IT部門合做的時候該如何作？

他們經過與合適的人交談來作到這一點。

• 當麗塔須要一個新的軟件功能時，她能夠告訴約翰，但約翰的經理（安德魯）最終決定是否添加，以及將添加哪些功能。
• 當你想要新功能甚至修復一些錯誤時，是須要與安德魯交流的。安德魯是IT經理，他告訴約翰（或IT的其餘任何人）下一步該作什麼。
• 麗塔不能忽視安德魯，由於這是IT部門的規則：安德魯作決定。你必須按照安德魯想要的方式提出你的想法，不然他們會被拒絕。當要求對IT不符合方式且沒有意義的時候，要求會自動被拒絕。
• 安德魯是IT BC的反腐敗層，沒有什麼決定可以跳過他，它適合於IT部門的內部組織。

類比到代碼

這些例子很簡單，但咱們的代碼呢？咱們確實但願咱們的BC可以解耦，因此BC1不該該知道BC2。好吧，這個想法是一個BC不該該知道其餘BC的內部，這兩個可使用公共對象（DTO）直接將消息傳遞給另外一個或者是專門的適配器，它知道如何與兩個BC通訊。雖然經過域事件（基本上是更高級別使用的觀察者模式）的首選方法。

結束語

哇，很長的帖子，但我但願你如今對一個有限的背景有一個很是明確的理解。如下是常見有界上下文的一些示例：應用程序自己，UI層，域層以及它們的最小BC：對象，任何對象。

參考

DDD - The Bounded Context Explained