DDD
把統一語言拆成多個較小語言，然後將每個語言指定可以應用它的明確上下文：Bounded Context
首先在領域模型當中會遇到的是同一個專業術語，有可能會有不同解釋與使用方法，在共用享統一的領域模型，模型的複雜度會增加，團隊和溝通協作容易搞混。
為什麼會需要Bounded Context
我們來看看GPT給的解釋
在領域驅動設計（Domain-Driven Design，DDD）中，限界上下文（Bounded Context）是用來劃分系統中不同領域模型邊界的核心概念。它明確界定了特定領域模型的應用範圍，並確保在該上下文內，模型和術語的一致性。
限界上下文的要點包括：
模型的邊界： 每個限界上下文都有自己的領域模型和業務邏輯。不同的上下文可以針對同一個概念有不同的解釋和實現。例如，"客戶"這個概念在銷售系統和財務系統中的含義和處理方式可能完全不同，這時它們就應該位於不同的限界上下文中。
語言一致性： 在限界上下文內，開發團隊使用統一的語言（Ubiquitous Language）進行交流。這意味著在該上下文內，所有人對術語的理解是一致的，從而避免了溝通中的混淆和誤解。
系統劃分： 系統可以劃分為多個限界上下文，每個上下文之間相對獨立，可以有不同的技術棧、架構模式和開發節奏。這樣的劃分有助於降低系統的複雜性，並允許不同團隊專注於各自的領域。
上下文映射： 當系統中的多個限界上下文需要交互時，可以使用上下文映射來定義它們之間的關係。這包括客戶-供應商模式、防腐層等，用來管理不同上下文之間的整合和依賴。
使用限界上下文的目的：
- 解決模型混淆：防止在不同業務領域中對相同術語的誤解和混淆。
- 提高團隊效率：使得各團隊可以在自己的限界上下文內獨立工作，減少相互影響。
- 支持系統演進：允許領域模型在局部範圍內演進和變更，而不會影響整個系統。
待補中
元哥的筆記