現實世界中領域和子域

領域中還同時存在問題空間（problem space）和解決方案空間（solution space）。在問題空間中，我們思考的是業務所面臨的挑戰，而在解決方案空間中，我們思考如何實現軟件以解決這些業務挑戰。以下是如何將這兩者應用到我們已經學過的知識中：

? 問題空間是領域的一部分，對問題空間的開發將產生一個新的核心域。對問題空間的評估應該同時考慮已有子域和額外所需子域。因此，問題空間是核心域和其他子域的組合。問題空間中的子域通常隨著項目的不同而不同，他們各自關注于當前的業務問題，這使得子域對于問題空間的評估非常有用。子域允許我們快速地瀏覽領域中的各個方面，這些方面對于解決特定的問題是必要的。

? 解決方案空間包括一個或多個限界上下文，即一組特定的軟件模型。這是因為限界上下文即是一個特定的解決方案，它通過軟件的方式來實現解決方案。

通常，我們希望將子域一對一地對應到限界上下文。這種做法顯式地將領域模型分離到不同的業務板塊中，并將問題空間和解決方案空間融合在一起。在實踐中，這種做法并不總是可能的，但通過新的努力，我們是可以做到這一點的。讓我們考慮一個遺留系統，它有可能是個大泥球，其中子域和限界上下文存在相交的地方，就像圖2.1中所示一樣。在一個大型的企業中，通過對問題空間的評估，我們可以減少錯誤，進而降低成本。我們可以在概念上使用兩個或者多個子域來分解限界上下文，或者將多個限界上下文包含在同一個子域中。為了澄清問題空間和解決方案空間的區別，讓我們來看一個例子。

讓我們來看看一個大型的ERP系統。嚴格地講，我們可以將一個ERP系統想象成一個單一的限界上下文。然而，由于ERP系統提供許多模塊化的業務服務，將不同的模塊看成不同的子域是有好處的。比如，我們可以將庫存模塊和采購模塊拆分成不同的邏輯子域。我們將它們分別命名為庫存子域（Inventory Subdomain）和采購子域（Purchasing Subdomain），在下文中，我們將講到為什么這種劃分是有用的。

圖2.4表示一個ERP系統的領域，也是圖2.2中所示模板的一個實例。該企業計劃開發一個特定的領域模型來降低成本，該模型可以為采購人員提供決策工具。從多年人工處理過程中積累起來的算法將通過軟件實現自動化。這個新的核心域可以大大地提高該企業的競爭優勢。為了能準確地管理庫存，可以借助圖2.1中的預測系統。

在我們實施某個解決方案之前，我們需要對問題空間和解決方案空間進行評估。為了保證你的項目朝著正確的方向行進，你需要先回答以下問題：

? 這個戰略核心域的名字是什么，它的目標是什么？

? 這個戰略核心域中包含哪些概念？

? 這個核心域的支撐子域和通用子域是什么？

? 如何安排項目人員？

? 你能組建出一支合適的團隊嗎？

如果你不了解核心域的目標及其所需的支撐子域，那么你是不能從核心域中得到好處的，同時你也無法避免由此帶來的陷阱。因此，我們需要全面地對問題空間進行評估，并確保所有的利益相關方在核心域的目標上都達成一致。

白板時間

看看你白板上的內容，然后想想：你的問題空間是什么？再回想一下：問題空間由戰略核心域及其支撐子域組成。

在理解了問題空間之后，我們來看看解決方案空間。對于問題空間的評估也是有益于理解解決方案空間的。解決方案空間在很大程度上受到現有系統和技術的影響。這里，我們應該根據分離的限界上下文仔細地思考，考慮以下問題：

? 有哪些軟件資產是已經存在的，它們可以重用嗎？

? 哪些資產是需要創建的，或者從別處獲得？

? 這些資產是如何集成在一起的？

? 還需要什么樣的集成？

? 假設已經有了現有資產和那些需要被創建的資產，我們還需要做些什么？

? 核心域和那些支撐項目的成功幾率如何？會不會出現由于其中一個失敗而導致整個項目失敗的可能？

? 在哪些地方我們使用了完全不同的術語？

? 限界上下文之間在哪些地方存在概念重疊？

? 這些重疊的概念在不同的限界上下文之間是如何映射和翻譯的？

? 哪些限界上下文包含了核心域中的概念，其中使用了哪些[Evans]中的戰術模式？

請記住，開發核心域的解決方案是一種關鍵性業務投入。

在圖2.4中，用于捕獲決策工具和算法的采購模型表示了核心域的解決方案。該領域模型將在最優獲取上下文（Optimal Acquisitions Context）中實現，該上下文與最優獲取核心域（Optimal Acquisitions Core Domain）存在著一對一的關系。由于只對應于一個子域，同時又擁有優秀的領域模型，這個最優獲取上下文將會是業務領域中最好的限界上下文之一。

除了最優獲取上下文，還有采購上下文（Purchasing Context）。該上下文用于輔助最優獲取上下文，以改進采購過程中的技術細節。這些改進并不顯露最優采購上下文中的特定信息，只是簡化了最優采購上下文和ERP的交互，也即是一個用于操作ERP接口的便捷模型。這個新的采購上下文和先前的ERP采購模塊同屬于采購（支撐）子域。

整個ERP采購模塊是一個通用子域，你甚至可以購買另外的采購系統來替換該子域，只要它滿足你的業務需求即可。然而，在采購子域中，我們將該采購模塊與采購上下文共同使用，這使得該模塊多少有些支撐子域的意味。

你所不能改變的

在一個典型的不健康的企業系統里，你通常會面臨如圖2.1和圖2.4所示的情形。在設計欠佳的軟件里，子域和限界上下文之間很難存在一對一的映射關系。這種劣質軟件的大量存在已經成為事實，并且是你所不能改變的事實。你只能盼著在項目中通過合適的手段實施DDD，但最終你都需要和那些“不健康”的領域進行集成。因此，當你在分析某個“不健康”限界上下文中的多個隱式模型時，請好好溫習一下本章前面所教給你的那些技能。

在圖2.4中，最優獲取上下文還需要和庫存上下文（Inventory Context）進行交互。庫存系統用于管理倉庫中的物件，它使用ERP的庫存模塊，該模塊位于庫存（支撐）子域中。為了給貨遞合同方提供方便，庫存上下文還采用了第三方的地圖服務。對于庫存上下文而言，地圖服務并沒有什么特別之處，你可以選擇多種地圖服務。地圖服務本身只是一個通用子域，它被支撐子域所消費。

請記住這些從最優獲取上下文的角度所看到的關鍵點。雖然在問題空間中地圖服務是庫存子域的一部分，但是在解決方案空間中，地圖服務并不屬于庫存上下文。在解決方案空間中，即便地圖服務由基于組件的API提供，它依然屬于另外一個限界上下文。庫存管理和地圖服務所使用的通用語言是相互排斥的，這意味著它們屬于兩個不同的限界上下文。當庫存上下文需要使用外部的地圖上下文（Mapping Context）時，它們之間的數據交換需要一定程度的翻譯才能完成。

另一方面，從地圖服務提供商的角度來看，地圖子域便是他們的核心域了。他們擁有自己的領域和業務模型，同時他們需要不斷改進自己的領域模型以保持競爭力。如果你是某個地圖服務提供商的CEO，你需要采取不同方法留住自己的客戶。然而，對于庫存系統來說，地圖服務始終還是個通用子域，你完全可以轉向另外的地圖服務提供商。

白板時間

在你自己的解決方案空間中，限界上下文是什么？此時你可以參考先前所繪的框圖。隨著我們對限界上下文講解的深入，你可能感到有些驚訝了。因此，你應該為有可能的改進做好準備，畢竟，我們采用的是敏捷方法。

為了平衡各個知識點，接下來我們將講到在解決方案空間中，限界上下文作為一種建模工具的重要性。在上下文映射圖（3）中，我們將主要講解如何通過集成限界上下文的方式來完成不同通用語言間的映射。