12月19日，第四届领域驱动设计峰会（DDD Conference）再度开启。不同于往届的线下举行形式，本届峰会采取线上的形式，致力于打造一场架构设计和技术实践的盛宴。作为软件架构设计新的潮流，领域驱动设计（Domain Driven Design，简称DDD）强调业务和技术的统一性，为复杂领域软件工程的设计决策提供实践框架，帮助企业不断拓展数字化业务。

2020年，一场突如其来的全球公共卫生事件对于人们的生活与工作产生了巨大的影响，各行各业积极应对挑战。业务的剧变对架构平台带来了巨大的冲击，如何客观地评估分析架构现状、该从哪些维度设定架构演进的目标，又如何引导架构增量地向目标演进，成为当下企业持续探索的命题之一。

领域驱动设计峰会（DDD Conference）是由国内领域驱动设计（DDD）思想和实践的领军者——ThoughtWorks的架构咨询师们组织发起，希望为国内的领域驱动设计（DDD） 实践者们提供一个互相交流、分享自己团队的成功经验的平台，使得领域驱动设计（DDD）的架构思想能够在国内被更多人所认知，从而形成更大的规模效应。

六大主题分享全景呈现DDD新常态

本届峰会邀请了ThoughtWorks全球技术总监及软件架构师Neal Ford、Unisys首席应用架构师与全球DDD社区领袖Indu Alagarsamy等来自海外的领域驱动设计（DDD）的领军人物分享在架构设计领域出现的新的尝试和探索。

同时，民航信息技术总监张逸、IBM资深应用架构师于静、《中台架构与实现：基于DDD和微服务》作者欧创新等国内持续实践领域驱动设计（DDD）的代表和思想领袖也分享了他们在各个不同场景下对于使用领域驱动设计的感悟和总结，展现了在后疫情时代领域驱动设计将会出现的新变化。

不论是演讲嘉宾还是话题设置，本次峰会既呈现了DDD的现状与未来趋势，又展示了DDD的最佳行业实践，全方位呈现了DDD的发展情况。

构建演进式架构

在过去十年中，DDD的限界上下文概念影响了软件架构，并启发Neal Ford产生了《演进式架构》书中的一些思想。作为ThoughtWorks全球技术总监及软件架构师，Neal Ford是国际公认的软件开发和交付方面的专家，尤其是在敏捷工程技术和软件体系结构的交集方面，以及DDD如何启发他产生了软件架构的量子概念。

业务实践在变，工具和框架在演进，创新的工具和技术不断涌现，这让软件开发生态体系也是瞬息万变。在过去的几年里，软件开发核心工程实践的渐进发展，让开发者重新思考架构是如何随着时间的推移而变化的，以及重要的架构特征如何能够在架构演进过程中得到有效保护，这促使Neal Ford与ThoughtWorks全球CTO Rebecca Parson博士一起总结提炼了演进式架构的核心概念。

在峰会的主题分享上，Neal Ford讨论了有关可演进架构的两个关键洞察。Neal Ford指出，演进式架构是在当需求出现的时候通过适应函数来把握架构演进的方向，演进式架构随着系统和业务的增加而变化，而且能够保证用户得到想要的部分，追求性能上的优化，追求扩展性的不断提升。

演进式架构支持跨多个维度的引导性增量更改。演进架构从进化计算世界借鉴了适应度函数的概念，以定义所谓的架构适应性功能。这是对某些架构特性或架构特性组合提供客观完整性评估的一种机制，描述了一系列可用于验证体系结构适用性的工具。

Neal Ford表示，原子适应度功能是仅关注单个特征和体系结构的功能，而整体适应性功能则关注特征的组合，很多时候体系结构特征相互纠缠。一旦定义了这些架构适应性功能，企业需要持续集成、部署管道以及诸如此类的敏捷调整实践的领域。

演进式架构最初目的是研究适应度函数的可演进性，在此过程中，我们希望能够衡量特定架构风格的演进程度，虽然产生了许多代码级量度，但是这还不够。受到DDD的启发，Neal Ford提出了软件架构的量子概念。

架构量子是一种以软件架构表示的领域驱动设计中的有限上下文的想法。架构量子具有高功能凝聚力和同步通信的独立可部署组件。架构量子关注事物如何耦合在一起，不仅分析了架构，而且还分析了操作级别，并包含了数据库和用户界面等内容。

“架构量子对有限上下文的定义会有所不同，因为我们正试图衡量事物在生态系统中的耦合程度。我们确实想要一个有界上下文的概念，但要用架构术语来表达。我们希望它作为一个有用的架构分析工具。”Neal Ford说。

领域驱动设计和消息传递的融合

DDD不仅可以帮助企业敏捷地编写高质量的代码，还能使所编写的软件能灵活应对业务变化。当使用消息传递技术在清晰整洁和定义良好的限界上下文之间进行通信时，就可以消除时序上的耦合，结合DDD就能构建可以自治的微服务。

Unisys首席应用架构师、全球DDD社区领袖Indu Alagarsamy在分享中认为，DDD与作为软件技术的消息传递进行融合，也就是实现领域驱动设计与事件驱动架构相结合，构建可以随着业务变化而扩展的可靠系统。

Indu Alagarsamy还以电商场景进行了详细说明，销售、库存、运输等不同部门的员工使用的领域语言不同，领域驱动设计引入了限界上下文的概念。我们可以根据团队或部门拆分模型，进行上下文的划分和设计。这时上下文之间需要能够以一种自主且可靠的方式进行通信，这是事件驱动架构很好地与领域驱动设计结合的地方。

命令和事件都是消息，但是通过明确区分什么是命令、什么是事件，可以帮助我们更好地设计软件。然而如何设计一个具有事件、消息和命令的系统呢？这就需要引入事件风暴。事件风暴是一种了解业务流程的协作可视化方式，在讨论流程中的业务行为时，使用事件风暴，程序员和架构师能够找出信息流。

“我们要做的是编写符合业务需求的正确软件，了解重要的业务行为有助于编写正确的代码，并使软件与业务保持一致，事件和消息驱动架构可以帮助我们摆脱时间耦合，使软件组件具有自主性。随着对领域相关信息的了解越来越多，你可以不断的改进模型，使其变的更好。如果你想使模型中的上下文自治，可以使用事件在这些不同的限界上下文之间进行通信。”Indu Alagarsamy说。

同时，Indu Alagarsamy认为，微服务的本质在于服务需要自治，并可以根据数据做出决定，不需要不停地询问其他上下文。因此，事件作为在相同的限界上下文中进行通信的机制，变得非常重要。

领域驱动设计大揭秘

作为《解构领域驱动设计》作者，同时也是民航信息技术总监，张逸对于DDD有着自己的独特看法，比如数据驱动与领域驱动、领域驱动设计下的单体架构等。

张逸在主题分享中表示，数据驱动进入架构设计领域造成模型没有上下文的边界，而DDD引入了限界上下文，通过业务能力完成重用，进而确定领域模型的知识语境，让架构顺应业务的变化方向。

DDD的特点与价值在于它定义的模式，限界上下文与聚合是DDD的核心模式。限界上下文是架构层次的自治单元，是业务能力的重用而非模型的重用。而微服务的协作就是限界上下文的协作，领域驱动设计成为显学，进入黄金时代。

单体架构（Monolithic Architecture）是一种将所有功能打包在一个容器中运行的设计风格，一个实例中集成了一个系统的所有功能。从中大型项目的业务形态、复杂度及响应速度等维度看单体架构时可以发现它存在扩展性差、无法实现复杂业务、技术升级困难、开发效率低等问题。

张逸表示，常见的区分单体架构和微服务架构的做法并不正确，虽然没有限界上下文的单体架构可能导致“大泥球”，但是单体架构也要通过业务能力进行纵向切分。如果单体架构通过限界上下文进行边界控制，其实可以降低微服务架构风格的演化成本，也能规避过度微服务化带来的技术风险。

另外，张逸认为，领域驱动设计存在四大“天生不足”，比如领域驱动设计缺乏一个规范的过程指导，使得其缺乏可操作性；领域驱动设计没有匹配的需求管理体系等，为此，我们需要领域驱动设计统一过程，确保DDD的落地实施。

领域驱动设计在大型遗留系统改造中的实践

自领域驱动设计和微服务概念提出至今，越来越多的互联网巨头以及传统行业都开始对自己的遗留系统进行微服务改造，通过把系统拆分为更加灵活、有业务边界上下文、松耦合的服务来应对快速变化的市场。

IBM资深应用架构师于静在主题演讲中介绍了一个有着二十年历史并支撑百万交易额的电商平台如何通过DDD方法华丽转身的实践，从这个案例我们了解到遗留系统进行DDD改造过程中的点滴经验。

于静表示，为了加速数字化转型与业务模式创新实现，遗留系统的改造会面临很多难题，比如交付速度慢、应用架构不满足快速迭代需求、技术受限、维护成本高、业务流程复杂等。而在改造过程中，现有业务不能停，同时过程难控制、结果难验证等问题也非常突出。

为此，遗留系统改造实施需要确立目标与制定策略、业务梳理、服务改造、集成迁移测试、反馈。在DDD指导下，企业需要通过事件风暴对业务讨论，审视现有的业务逻辑，逐步用新应用程序和服务替换特定功能段，增量迁移旧系统。随着旧系统功能的更换，新系统最终取代了所有旧系统功能。

于静说，企业在遗留系统改造中应该遵循“先锋队、树立模范、大部队”的阶段性原则。具体来说，“先锋队”阶段是挑选规模较小、功能简单，业务较为独立的功能模块进行改造，随着老系统的功能越来越多的被微服务系统所代替，老系统也最终被替代。需要注意的是，当发生新老系统的功能切换时，应该逐步切换用户流量，对用户尽量透明，使得改造过程过渡平滑。

当中台遇上DDD，如何设计微服务？

当前，中台、微服务是业界关注的热点话题。如果将两者放到DDD的背景下，如何建立DDD、中台和微服务的统一语言？如何将三者融合完成协同设计？《中台架构与实现：基于DDD和微服务》作者、极客时间《DDD实战课》专栏作者欧创新在主题分享中回答了这些问题。

欧创新表示，从企业架构角度来讲，业务中台属于业务架构的范畴，业务中台重构的过程本质是基于复用目的的企业级业务架构重构。在业务量不大的时候，我们用传统的集中式架构就可以解决复杂问题。而当面对海量互联网业务比如双十一，企业原来的架构就不足以解决业务和应用的扩展性问题，因此我们需要将原来大的问题域拆小，将单体应用拆分为微服务，进而上云。所以，DDD和微服务都是解决复杂问题的设计思想。

在DDD概念里，如果只从业务架构角度分析的话，中台本质上是从领域到更细的子域划分过程中的一个桥梁，只从业务领域角度分析，它可能对应DDD领域中的某一个核心子域或通用子域。

对于DDD与中台和微服务的关系，欧创新认为，中台本质是领域中的某一个子域，需要抽象并标准化，按照单一职责原则建立可复用的领域模型。微服务是中台最佳技术实现。DDD是一种可以同时指导中台业务建模和微服务设计的方法论，遵循高内聚低耦合的原则，完成从业务端领域建模到应用端微服务实现的无缝落地。

我们看到DDD和中台设计两种知识体系的融合需要建立两者通用语言，团队通用语言也是DDD不断强调的内容。一般对于小的项目我们可以直接从问题域开始事件风暴，完成领域建模。而对于企业级中台而言，业务领域非常大，我们需要做好顶层设计，划分子域，确定中台的大致边界，然后基于这个边界开展事件风暴，划分限界上下文，完成领域建模，它是一个自上而下的设计过程。

“DDD博大精深，但DDD也不是万能的‘银弹’。将中台和DDD视作一种思维方式和设计思想，结合企业实际情况灵活运用才是王道。”欧创新说。

DDD从战略设计到代码落地的三阶段方法

ThoughtWorks总监级咨询师杨云指导过多个DDD实施项目的落地，在峰会的主题演讲上杨云系统介绍了如何将DDD建模在大规模开发团队的情况下确实的落地到代码层面。

为什么企业觉得DDD落地难？杨云表示：“首先，因为DDD进入了更深层的应用。DDD从战略层面的应用进入到战术落地层面，而不再仅仅停留在子域划分、微服务划分等。其次，参与建模的人，从业务专家和架构师级别的技术专家，深入到产品经理、软件工程师等执行具体事务的人员，面临在百人以上开发团队大项目上保证代码按照模型落地的难度。最后，DDD建模的投入和交付时间点的矛盾、DDD建模投入的即时性和DDD模型收益的长期性之间的矛盾。”

在DDD落地方面，企业需要对战术级别的建模提供更具体、更模式化的指引。对于大规模项目，设计更明确、与代码实现直接相关的微观模型。提供更好的工具降低DDD模型建设和维护成本，提高模型和代码一致性。

基于此，杨云提出了DDD落地的三阶段方法：事件风暴阶段聚焦战略建模、子域划分、微服务拆分；名词动词阶段，在子域或微服务内，细化实体和行为，识别重要角色和重要规则，建立子域内核心概念的结构化模型；类型流阶段，微观展开具体行为，将承载业务逻辑的纯函数和依赖基础设施的副作用函数剥离。

杨云表示，建模是迭代的，不是线性单向的。DDD建模需要考虑团队工作的细节层次，采取适当的方法：用事件风暴来做战略建模、用名词动词法做子域内的结构化战术建模、用类型流做行为内部的微观详细设计。

结语

DDD从2003年被提出来以后，得到了业界的高度认可，特别是微服务架构、中台等逐渐盛行，DDD正在加速在企业业务实践中的落地。而领域驱动设计峰会为DDD社区提供了一个绝佳的交流与分享平台，也将极大推动这种进程，更好地促进DDD的发展。