DDD作为企业架构方法论的三点不足

除了[[RUP、DDD、TOGAF三种架构落地方法论的优缺点对比|第1章已提到的”重设计轻过程/重概念轻规则/重现在轻过往”]]这三个缺点，如果换成”一套完整的企业架构方法论应该包含什么”这个更高的标准来衡量DDD，还能看出三点结构性不足。第一，企业架构方法论应当包含类似”架构愿景”的内容，把企业架构和企业战略关联起来（就像[[TOGAF双飞轮模型：方法为核心，工具与组织为支撑|TOGAF]]的阶段A就专门做这件事），但DDD中没有类似的内容——它没有回答”这套领域划分究竟服务于什么企业战略目标”这个问题。第二，企业架构方法论的核心应该包括一套类似TOGAF ADM那样的架构开发方法——提供一系列阶段、活动、任务说明，并配套工具、模型、模式的支持，以便更好地落地实施；但DDD仅仅提供了一系列概念及其解释（领域、限界上下文、聚合等），并没有针对架构落地过程给出明确的步骤指导，也没有提供相应的落地工具和模型——这正是[[DDD的本质：一套处理复杂系统的等级机制|“重概念轻规则”]]这个老问题在企业级视角下的另一种体现。第三，企业架构方法论应当包含架构治理相关的内容，也就是”架构设计出来之后该如何管理”，DDD在这方面同样缺乏对应机制。可迁移启发：如果团队打算把DDD当作企业级架构方法论直接套用，需要提前意识到它天生缺”愿景关联”“过程指导”“治理机制”这三块拼图——务实的做法是拿DDD负责领域拆分和限界上下文这部分擅长的工作，同时从TOGAF这类更完整的方法论里借用架构愿景对齐、开发过程指导、架构治理这几个环节来补齐短板，而不是指望DDD单独撑起整个企业级架构工作。