DDD的作用范围主要还是针对系统级的分析、架构与设计，在更高的层面上，即将问题空间扩大到超过系统范围，变成企业或组织范围之后，DDD的模式就显得捉襟见肘了。此时，可以考虑引入企业架构的思想，尤其是业务架构的内容，给了DDD很好的补充，又或者说，将企业架构与DDD融合起来，就能真正串联起战略和战术设计了。
为什么在传统企业中，DDD开始得到了许多企业的追捧？不仅仅是微服务的原因，就我个人不成熟的判断，应该是数字化转型开始倒逼着传统企业的IT部门开始接纳了DDD这一方法体系。
数字化转型对企业的要求，表现在以下方面：
- 企业架构与行业的结合程度
- 数字化的企业IT架构
所谓“行业”，也可以理解为“领域”，传统企业在互联网经济的冲击下，开始向更快、更强的要求转变，但真正的快，绝不是没有规划，恰恰相反，需要在战略上有着清晰的转型目标，而在战术（企业的战术层面，对应于DDD的战略层次）上需要沉淀企业的领域资产。不管这些领域资产是通过核心模型、服务还是其他组件形式，都需要对准转型方向的企业战略，并在战略指导下做到可复用业务能力的识别与沉淀。这个过程可以是计划式的，也可以是演进式的；可以是分解为服务的粒度，也可以是能力中心的粒度；可以采用领域驱动设计建立核心领域模型，也可以建立自治的微服务，也可以是中台的能力规划与战略。
数字化转型必然不仅仅是业务的转型，还包括IT架构的转型。当前的一个趋势是在基础设施上，向着云原生架构转变；在能力建设上，要改变组织模式，同时也要从项目思维向产品思维转变；同时，还要加强对数据的重视，全面拥抱互联网数据、物联网数据，做到业务与数据的双向支撑；在技术复用方面，也提出了前所未有的高要求，不管是PaaS、SaaS还是中台的能力中心，或者微小粒度的服务与组件，更或者是近期炒得火热的低代码平台，其核心关键还是遵循八二原则，尽可能将能够复用的技术实现、业务模型（包括流程与规则）的开发成本降低，如此就能满足快速开发产品服务不断应对产品创新的需要，又能合理分配人力成本，花更多人力与物力去做好高价值的东西。
要做好企业的数字化转型，就要“从企业整合运作、提升竞争力的角度出发，站在企业全局的高度，从理解企业所处行业、发展阶段、目标、战略、竞争环境等多方面入手，认清其核心能力及管理中存在的主要问题，在此基础上进行管控模式分析，提出关键业务流程的优化建议”[引自《微服务设计：企业架构转型之道》]，简单说来，数字化转型是企业层面的全面转型，同时也是企业高管的思维转型。为了规避风险，也为了企业的转型步子能够迈得更坚实，又需要根据轻重缓急分阶段实施。实施的过程必然是自上而下的，但是随着从顶层到底层的逐步细化，粒度也在不断缩小，待缩小到目标系统的层次时，就是DDD登上舞台的最佳时机了。
我曾经和多位业务架构师聊过企业架构与DDD的关系，窃以为企业架构在宏观层面上有着自己一套成熟的体系方法，如TOGOF和Zachman等企业架构体系，它庞大的规范、标准与过程非常值得IT部门学习，值得将其引入到数字化转型作为参考；然而，这些方法的问题在于：
- 过于复杂：虽然企业自身复杂度决定了体系的复杂性，但一套体系如果过于复杂，许多人穷其一生可能都无法掌握其全貌与细节，就很难掌控，更谈不上落地；
- 过于宏观：利用企业架构的思想和方法对企业做完战略规划后，如何保证方案的落地，又如何保证落地过程完全遵循解决方案的要求不偏不倚地推进，缺乏有效的手段。
企业架构就好似画出了企业战略规划的模板，模板中的空白部分就是落地需要的知识和能力。利用业务架构，已经对这些模板与空白进行了有效的切分，并明确了各自的边界，企业架构对业务架构向IT架构的映射给予了架构的指导，接下来，就可以通过DDD高质量地填充这些空白。
因此，企业架构与领域驱动设计是完全能够融合在一起的，促进这一融合的催化剂是数字化转型，呼唤这种融合的需求来自于相对高高在上的企业架构需要具备落地的能力，至于这种融合为何在现在开始提出或得到重视，是因为当下这个时代，具备了向这个趋势发展的天时地利与人和：
- 天时：数字化转型已经提上了大多数传统企业的议事日程，不得不上，也必须上，而且得快上；
- 地利：各种IT基础架构已经满足了这一要求，无论是云原生、微服务、大数据，还是所谓的中台，为这一融合打下了良好的基础，敏捷思想已经深入人心，IT的管理能力与构建能力得到了大幅度的提高；
- 人和：数字化转型让企业高层领导看到了转型的迫在眉睫，转型的战略规划与IT架构构建已经时不我待，业务人士与IT人士都看到了这一趋势，并开始打破业务与IT的壁垒，寻求全方位的合作。
如果说以上内容指出了这一融合趋势，回答了融合的必要性，那么该怎么融合的问题就摆上了议事日程，毕竟二者并不处于同一层次，关心的角色也可能在身份地位上存在天壤之别。我的一个粗浅想法，是希望借鉴DDD的方法与思想，寻求对企业架构做必要的精简和简化，核心价值仍然是领域（业务）驱动，然后尝试建立不同层次的架构体系，即建立组织级与系统级的架构，让企业架构方法与DDD方法各司其职，组织级的棘手问题交给企业架构，系统级的落地问题交给DDD。
以上观点很不成熟，个人对企业架构的认识也非常粗浅。从学习路线看，我算是自下而上的狂飙猛进，不再满足于领域驱动设计的系统层次，要向上开始向企业顶层设计“逆袭”，之后，不是高高在上去俯视IT众生，而是沉下心来，完成二者的真正融合——既要做得了规划，还能写得出方案，针对核心实现，还要能撸得出代码。如此就算是打通业务（领域）驱动的任督二脉了！
