业务变化不息，架构演进不止 第四届领域驱动设计峰会线上开启

2020年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引入了限界上下文，通过业务能力完成重用，进而确定领域模型的知识语境，让架构顺应业务的变化方向。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!