领域驱动设计兑现承诺了吗？
内容提要
领域驱动设计（DDD）降低软件核心复杂性，建模关键，映射问题空间到解决方案空间。DDD强调领域和模型区别，提供领域分类法和泛在语言。建模仍需直觉和经验，分治是解决复杂性方法之一，但DDD指导有限。有界上下文革命性概念，定义模糊，缺乏明确指导。DDD可选择合适科学方法和元素。
延伸解读
建模指导的缺失：DDD 的未竟之处
文章指出，DDD 虽强调建模重要性并提供了领域与模型的区别、子领域分类法和泛在语言等基础，但在如何评估模型质量、如何结构化表达模型、如何从非结构化知识中构建模型等关键问题上，指导几乎空白。建模者只能依赖直觉和经验，DDD 未能将建模从艺术推向可重复的工程实践。
分治的困境：有界上下文模糊，中层概念缺位
面对复杂领域，分而治之是控制认知负荷的必要手段，但 DDD 在此同样乏力。有界上下文（BC）概念虽具革命性，却定义模糊、高度主观；服务、聚合、实体等又过于底层。最需要指导的中层——如何组织模块与区域——DDD 没有给出明确方法，耦合与内聚仅停留在松散提示，导致实际分组挑战依旧。
可能的改进方向：融合科学方法与语义分析
作者认为，若 DDD 能摒弃部分低层且相对无用的概念，转而精心选择承诺理论（合同）、耦合与内聚二分法的科学方法，或领域语义分析（如术语的概念“接近性”、“能力”定义），本可更有效地应对日常建模难题，例如判断“折扣”应归属“项目定价”还是“购物车折扣”，或从四种视角中组织快递递送模型。
Q&A
DDD 在控制软件复杂性方面到底有没有兑现承诺？
文章认为 DDD 在降低复杂性方面有贡献，但并未完全兑现承诺。它强调建模的重要性，提供了领域与模型的区别、子领域分类法和泛在语言等基础，但在建模的形式化、分治指导、有界上下文的明确定义以及中层模块组织等方面指导不足，导致实际应用仍面临挑战。
DDD 中的“建模”具体指什么？为什么它重要？
建模是将问题空间（领域）映射到解决方案空间（模型）的过程。由于现实无限复杂，模型是经过简化和过滤的、与当前环境相关的现实版本。DDD 强调建模的重要性，并提供了领域与模型的区别、子领域分类法和泛在语言（UL）等概念来辅助建模。
有界上下文（Bounded Context）在 DDD 中是如何定义的？它有什么问题？
文章指出有界上下文是一个革命性但定义极其模糊的概念：它是模型的一部分，UL 在其边界内保持一致，直观地聚合了合作群体意识中的焦点概念。它非常主观、依赖观点而非事实/测量，且层次很高，缺乏具体的组织指导，导致在实际应用中难以把握。
DDD 在分治（将大模型拆分为小部分）方面提供了哪些指导？
DDD 提供了有界上下文、服务和聚合等心智模型，但这些远远不够。有界上下文层次太高，服务和聚合层次太低，而最需要分组的中层（区域/模块/应用的组织）缺乏明确指导。DDD 虽提到耦合和内聚，但只是松散指导，没有形成规范性的基础。
文章认为 DDD 可以如何改进以更好地解决实际问题？
文章建议摒弃领域服务、聚合或实体等低级且相对无用的概念，同时精心选择承诺理论（合同）、耦合与内聚二分法的科学方法或领域语义分析（术语的概念接近性、能力定义等）等元素，结合更科学的方法和领域语义分析，DDD 可能会更有效地解决实际问题。
在实际建模中，DDD 为什么难以区分好模型和坏模型？
文章指出 DDD 没有提供区分好模型和坏模型的质量功能，也没有给出表达模型的好方法建议。建模过程几乎只能依靠本能、直觉和个人经验，DDD 在如何结构化原始知识、包装知识以供复用方面帮助有限，因此难以评估模型质量。
