我剛剛讀過Vaughn Vernon的「實現域驅動設計」一書，我對有界上下文如何與應用程序保持一致感到困惑。DDD - 有界的上下文和部署單位
一個應用程序中是否可以有幾個有界的上下文？如果是這樣，什麼決定了一個上下文應該與另一個上下文一起部署還是應該作爲一個獨立單元部署？
如果我在一個應用程序（部署單元）內有多個有界的上下文，並且一個客戶端（例如一個UI）需要來自多個上下文的信息，我應該創建一個新的應用程序服務來支持這種情況然後？
一個應用程序中是否可以有多個有界的上下文？
您可以選擇將組織多個圍成的單個應用程序中的上下文，選擇什麼樣的命名空間/文件夾，將它們分開：
/domain /Claims /Policy.cs /Inspections /Policy.cs /Underwriting /Policy.cs
（以下簡稱「政策」的例子是DDD蒸餾水）
這種方法的優點是簡單，雖然它有許多缺點：
如果有的話，確定是否上下文應連同另一種情況下，或者如果它被部署應該作爲一個獨立單位進行部署？
你必須考慮讓他們在單個應用程序中分裂的優缺點。其中一些我已經在上面提到過，但還有其他的事情要考慮。
不同的上下文是否有不同的非功能需求？即縮放，性能需求等？如果是這樣，你會希望能夠單獨部署它們，所以它們不應該是同一個應用程序的一部分。
您是否受限於您可以選擇的技術或可以部署到的服務器？可能存在一些限制，使其更難轉向更微觀的服務風格架構。
這個問題還有一個組織因素，它取決於你所在組織的類型。你有多個團隊在你的系統上工作嗎？如果您在一個主要業務是IT基礎的組織中工作，那麼您通常會發現該業務已經爲您做出了一些決策，因爲他們組織了團隊和結構（請參閱康威法律）與上下文保持一致。這個部門是否是你真正想要/正確的是另一個問題。在其他組織中，您可能是「IT部門」或更一般的東西，在這種情況下，您可能會對如何建模和組織事物有更多的控制權。
如果我有多個一個應用程序（部署單元）內的限界上下文，以及客戶端（例如一個UI）需要在同一時間從幾個上下文信息，我應該爲了支持創建新的應用服務那麼這個場景呢？
作爲@plalx在評論中提到，您可以在客戶端或服務器端執行此聚合。想象一下帶有3個小部件的頁面，其中每個小部件對不同的上下文進行AJAX調用（如果將它們分開）並以這種方式組成UI。或者，您可以聚合服務器端，即對於所討論的UI具有某種讀取模型。
您可以有多種集成方法。 UI可能屬於特定的上下文。您可以在其中構建用戶界面的複合用戶界面由聚合多個屬於並保存在不同BC中的組件構建而成。您可能還有一個與多個BC進行通信的UI或在後端執行聚合。所有的集成方法都是可行的，並具有優點和缺點。您可能需要閱讀領域驅動設計的模式，原則和實踐，其中有一章。 – plalx