领域驱动设计并不牵涉到技术层面的实现细节。
”对一个大型系统，领域模型的完全统一将是不可行的或者不划算的。“ -- Eric Evans
DDD的构建块不能盲目地应用在一个无限大的领域模型上，一个无限大的领域模型也无助于我们开发出优质的软件，限界上下文是分解领域模型的关键。
限界上下文的边界，也是需求和模型的边界
如果发现了了通用语言中的歧义，往往意味着有隐藏的限界上下文要识别
将新的通用语言和限界上下文加入到团队中来，这些变化可能会影响业务分析和信息架构
• 通过组织架构、业务模式的分析构建出业务全景，找到业务领域及子领域
• 分析不同业务领域的流程、渠道触点、运作模式的异同，来找出业务服务；
• 不同业务服务中重叠的子领域/限界上下文，即潜在的基础服务
• 限界上下文即潜在的服务边界
首先，最大好处就是所有参与者围绕一个统一一致的领域模型工作，传统的分析模型和设计模型不再割裂，不管是做设计、做分析还是写代码、写文档，脑海中所构建的画面都是一致的。
第二，DDD 是一个软件开发过程，它显式地把领域和设计放到了软件开发的核心，软件人员和业务人员被受到同样的重视，他们合作来构建领域模型，使得软件的交付质量更高且维护成本更低；
第三，DDD 提出的分层架构，有效分离了业务复杂度和技术复杂度，凸显了领域模型，使得领域层的代码和领域模型保持高度一致；
第四，统一语言非常重要，每个概念在各自的上下文中是清晰的无歧义的，同时要控制领域模型的复杂度，于是 DDD 在战略上提出了分离子域（问题域空间）和拆分 BC（解决方案空间）的模式，BC 间通过 Context Mapping 来集成；
第五，DDD 在战术层面提出了很多模式（聚合，实体，值对象，服务，工厂，仓储），对领域模型中的元素进行了分类，并给出了每类元素在领域模型中的职责和特征，降低了领域模型的构建成本。