文章目錄
1 從哪裏來到那裏去
限界上下文從何而來，他不是一個從天而降的概念，一切都有跡可循。讓我們回到現實世界思考。
1.1 問題空間與解空間
開發軟件實際是要爲用戶解決現實中存在的某一類問題或爲其帶來某一領域的變革，在對用戶問題進行分析及解決過程中我們劃分了問題空間及解空間兩個維度的空間。用通俗的描述問題空間是我們對現實世界問題的認識及描述，解決空間是對問題空間中問題的解決結果及方案。
從一個現實中的例子出發，比如需要砸一堵堅硬的牆，如何砸牆屬於問題空間，而鐵錘是該問題的一種解決方案屬於解空間。
1.2 問題空間的來源
我歸類我們行業問題空間來源於兩個途徑
- 解決痛點 ：例如企業信息難以管理，企業受迫於信息化不健全，在進行企業信息時相當困難。
- 爲用戶帶來變革 ： 例如網購，購物等在網購出來前大家都習以爲常，但網購的到來對人們購物方式發生了巨大的變革
1.3 對問題的拆分
很多時候大泥潭系統的產生並非開發過程不規範，而是在問題分析階段就未認真對待，使得一個服務承擔了一整個問題空間，所有的業務混雜一起，承載了太多的業務知識，開發人員理解起來難，開發起來更難。而將龐大複雜的大問題化爲單一類似的小問題，這也是從源頭上避免了大泥潭式系統。
分治算法給予了我們解決一個大問題的靈感，由大化小，並逐一擊破。當我們在爲客戶開發一套系統解決客戶領域內的問題時，也會形成複雜龐大的問題空間。若不對大問題進行拆分，一個完整的問題空間中，包含了各類複雜無序的業務規則，系統的開發效率及質量都將受到衝擊，那麼對大問題的拆分就很有必要了。
以一個門店管理系統的問題分析階段爲例，我們對其問題空間進行拆分，劃分出以下問題域：
- 會員問題域 ： 對門店會員管理上的問題；
- 財務問題域 ： 門店進行財務營收統計上的問題；
- 營銷問題域 ： 門店商品推廣上的問題；
- 員工問題域 ： 門店的員工管理問題；
- 交易問題域 ： 門店進行交易上的問題，是客戶最希望解決的問題，爲核心問題域；
我們重點關注該問題中的核心交易域，在交易問題域中我們進行了進一步的拆分得到了訂單子域、結算子域、售後子域。對問題的拆分是無限制的，子問題可以被劃分爲更小的問題。
1.4 對問題的解決
拆分完畢問題空間，我們需要做到逐一擊破，爲每一個問題形成一套落地解決方案。一個問題對應一個答案，解空間與問題空間基本上應該是一一對應的。
我們給出的解方案是一個個限界上下文(圖片簡稱BC)，一個限界上下文負責應對其對應的問題進行解決，承載了該問題中的業務知識及規則。
2 限界上下文的作用
限界上下文是解決某一類問題的單一功能模塊，例如訂單限界上下文，處理開單、通知訂單狀態等一切與訂單關聯的功能，當前你可以理解爲一個微服務，在之後我會解釋其與一個服務有何區別。
2.1 統一語言的邊界
隨着問題的劃分，將領域拆分成了不同的子域，每個子域有其獨有的業務知識，而這些知識需要靠一門統一語言來描述。而不同限界上下文間的統一語言是相互獨立的。可能在不同的限界上下文有同樣的名詞，但同樣的名詞在不同的限界上下文中可能表示的不是同一事物，即使是同一事物可能其在不同上下文中的關注點也不一致。
2.2 領域模型的邊界
限界上下文是領域模型的邊界，領域模型用限界上下文中的統一語言描述，領域模型是對現實業務的體現。
2.3 代碼的邊界
每一個限界上下文是一塊獨立的功能代碼
3 子域、限界上下文、服務間的關係
對這三者間關係的提問是我遇到最多的，往往對限界上下文的不清晰來自與另外兩部分的界限不清晰。
3.1 子域與限界上下文
子域是來自問題空間，而限界上下文相當於是對子域的回答。
3.2 限界上下文與服務
之前所說限界上下文是代碼的邊界，而其作爲代碼的邊界可以有以下兩種：
- 包、模塊級別隔離
- 服務隔離級別
經常遇到有人將限界上下文與服務劃等號，其實非也，兩者可以說是毫無關聯的，僅僅是第二種服務間隔離級別恰好一個服務等於一個限界上下文。
服務是運行部署的單位，而限界上下文是某一領域功能集合，一個限界上下文儘量保證與一個服務對應。但當項目發展初期，可以將多個限界上下文放於同一個服務中部署，只要嚴格遵守限界上下文間的集成規則，同樣可以保證架構的清晰整潔。
在項目發展初期，交易服務內有訂單上下文、結算上下文、售後上下文，當業務發展到一定規模後將這些上下文脫離成獨立的服務。
關於限界上下文間的集成模式是相當關鍵的，將單獨一文闡述。