转载

三大亮点 ThoughtWorks DDD峰会的变与不变

至顶网软件与服务频道消息：数字经济时代，日益复杂的企业数字化业务不断扩展，对软件系统也不断提出新的挑战，DDD正成为软件架构设计新的潮流，以领域模型为核心，为复杂领域软件工程的设计决策提供实践框架，可在更大范围帮助业务实现快速响应，优化组织合作。

近日，全球领先的软件及咨询公司ThoughtWorks主办的第三届“领域驱动设计中国峰会”在北京成功举行。作为领域驱动设计（Domain Driven Design，简称DDD）思想和实践的领军者ThoughtWorks携手来自民航总局、戴姆勒、中兴、亚马逊、京东、携程、广联达等多家知名企业的资深架构师们与众多DDD实践者们共聚一堂，探索领域驱动设计及其“协作设计”的思想如何在实践中为中国产业信息化赋能。

峰会三大亮点

2017年，由ThoughtWorks发起，在众多DDD专家及DDD实践者、爱好者们共同的努力下，首届“领域驱动设计中国峰会”正式扬帆起航。今年是“领域驱动设计中国峰会”的第三界，大会在内容上也更加多元、有趣，围绕“领域驱动的统一语言”、“统一驱动的协作设计”、“领域驱动的架构演进”三大主题展开深入讨论。来自各行业资深架构师们的分享，更是涵盖了从高精尖的航天工程，到大众熟悉的银行、保险、网络购物等方方面面，足以彰显DDD在各个行业中的广泛应用。

作为大会话题的出品人，民航（成都）信息技术总监张逸从第一届大会开始就深度参与。他表示，今年大会与往届有三大不同点。第一，跨界。今年大会增加了设计域、业务分析、设计体验等话题。第二，紧跟行业技术发展，比如大会探讨了微服务、中台等最新技术热点。“我觉得紧跟最新技术发展，让它和领域驱动设计结合起来，这个很重要。作为出品人，在话题上我们会尽量贴近热点。”

三大亮点 ThoughtWorks DDD峰会的变与不变

张逸说，虽然我们在保持与时俱进，但是要守住DDD的本质，不能什么都往DDD里面放。同时，一些传统的业务范畴也可以放到DDD里面，比如业务架构。因为业务架构属于企业架构思想，并不局限于软件工程，而是IT战略规划。“跨界，纳新，让我们接入的东西发挥新的作用，这是今年峰会的三大亮点。”

DDD的变与不变

2014年，微服务概念的火热带动了DDD的概念被业界重新认知。在随后的5年中，领域驱动设计在架构设计过程中的重要作用逐渐被业界主流所接受。无论是微服务架构、演进式架构、还是企业IT架构设计、企业中台设计，领域驱动设计在各个架构设计层面都发挥着自己的价值，不断推陈出新。

近年来，经过DDD实践者们的不断努力，领域驱动设计被运用于众多企业的实践之中，虽然规模还有待进一步扩大，但成果已相当丰厚。无论是在微服务的应用背后，还是在中台从规划到落地的过程中，再或是在嵌入式C系统重构到领域模型，以及大型寿险核心系统改造项目中，领域驱动设计架构都有不错的表现。2019年“领域驱动设计中国峰会”，正是一次对国内领域驱动设计实践的检阅和展望。比如京东7FRESH系统架构负责人阎华在会上分享了京东7FRESH的全渠道零售系统构建领域模型的实际操作。

张逸回顾了领域驱动设计的历史，他讲述了DDD的四大里程碑，那就是2004年DDD的提出、领域事件的引⼊、微服务的引⼊和中台战略的引⼊。领域驱动设计（DDD）的概念源于2004年著名建模专家Eric Evans，领域事件的引⼊带来建模范式和架构风格的改变。

微服务的引入是第三个里程碑，其带来了设计理念的改变，从某种意义上微服务的产生催生了DDD中国峰会。张逸表示，领域驱动设计的模式与实践降低了从单体架构迁移到微服务架构的⻛险，因此微服务与领域驱动设计是天作之合，微服务架构采用了领域驱动设计会让微服务的架构迁移更加容易。现在中台的概念非常火，其实DDD与中台的理念也不谋而合。中台是企业级能力复用平台，而DDD与中台融合也就是领域模型的复用。

基于这样的思考，张逸给出了领域驱动设计的新定位，也就是DDD不是技术，而是一种哲学。张逸还引入了领域驱动设计魔⽅，其X轴限定领域驱动设计的内容，Y轴分离领域驱动设计的层次，Z蕴含了轴领域驱动设计的实践。“哲学意味着DDD变成一个框架，可以容纳很多东西，因此我总结了领域驱动设计魔⽅扩大了DDD的外延，对DDD进行了一次重新定义，但也要注意领域驱动设计不能解决所有的问题，也不能什么内容都往DDD里面装”

具体而言，领域驱动设计魔方将X轴分为业务、技术与管理三个维度，在Y轴则将整个系统的层次分为宏观层次、微观层次和纳米层次。宏观层次是针对整个软件系统开展的战略宏图规划与战略概要设计，通常分为两个阶段：全局分析阶段和战略设计阶段；微观层次是承上启下的关键环节，是领域驱动设计在团队中落地的重要前提；纳⽶层次对应于软件开发过程的实现阶段。X轴和Y轴的相交分别对应Z轴的方法、模式与实践。

领域驱动设计魔⽅引入了业务架构、事件⻛暴、架构模式、RAID⻛暴、康威定律、精益需求管理与敏捷过程管理、场景驱动设计与测试驱动开发、测试策略。

DDD落地的路很长

虽然目前DDD的声音越来越“高”，但是DDD的发展任重道远。

谈及在企业中的落地，张逸表示，DDD不一定适合所有的项目产品。从产品角度看，领域模型的建立需要时间和成本。而且项目的交付需求不同，特别是在国内这种软件交付语境下，DDD还是受到很大挑战的。因为国内的软件项目，从招投标到评审、交付都有自己的特殊流程，DDD有时是无法满足的。从团队角度看，一个好的符合DDD的团队是必不可少的。如何提升项目团队的DDD能力，并应用到项目中，这是一个漫长的过程。“DDD好，但是落地还是有很多的障碍和困难，这就需要我们不断推动，改变思维。”

张逸说，DDD近些年受到业界的关注这是很好的变化，因为DDD的价值显现出来了。如果说几年前大家对于DDD还很陌生，甚至很多人都没有听说。这些年，DDD受到了架构师的青睐。“这是因为企业的高层开始了解到DDD，自上而下推动DDD在公司内的部署和实施。同时类似DDD峰会这样的活动也让业界更加了解DDD。”

现在对于DDD关注的企业大致分为三种类型：第一种是了解DDD，但是没有计划落地，处于观望期；第二种是尝试落地DDD，但是缺少协作的方式；第三种是已经落地DDD并拥有一套比较成体系的方法和过程。

为了帮助企业更好地落地DDD，张逸提出了领域驱动设计参考过程模型和领域驱动设计能⼒评估模型（Domain-driven design Capability Assesment Model，DCAM）。其中领域驱动设计参考过程模型固化领域驱动设计的过程，提供简单有效的实践⽅法，建⽴具有⽬的性和可操作性的研发过程，包括全局分析阶段、战略设计阶段、领域模型驱动设计阶段；领域驱动设计能⼒评估模型，是⼀套评估模型，提供了对软件产品实施领域驱动设计的评估指标，指导团队进⾏能⼒的培养和提升。

张逸表示，DCAM并⾮⼀个标准或⼀套认证体系，更⾮事先制定和强制执⾏的评估框架。建⽴这套模型的⽬的仅仅是为了更好地实施领域驱动设计，它是⼀个能够不断演化的评估框架。评估维度分为敏捷迭代能⼒、领域建模能⼒、架构设计能⼒和整洁编码能⼒。

根据能⼒⽔平，DCAM分为三个等级层次，分别是初始级、成长级和成熟级。“这三个层次里边我们看迭代能力，初始级传统的组建团队，交流很少，需求没有很清晰，响应变化的能力很差。成长级就建立了特性团队。成熟级别还希望形成知识的共享，能够更好地梳理需求，最后形成可视化的看板，保证由下游拉动需求，消除浪费。”张逸说。

张逸表示，DDD的落地需要一个驱动力，提升你的能力，这包括个人、团队和企业三个层面，缺一不可。企业层面更多是制度、文化、流程，团队更是交流协作，个人是能力提升。“只有当更多架构师加入到领域驱动设计的行列，一起探索领域驱动设计，才有希望在软件行业更大范围、更深层次展开实践，结出更丰盛的果实。”

同时，DDD的应用场景也在不断延展，比如前端、用户体验、AI、大数据乃至于需求等都可以引入DDD领域建模的思想。“DDD的发展不要盲目扩大，而是守住一条线，你可以引用、借鉴。希望明年DDD峰会能够有更多角色的人员加入进来，共同推动DDD的发展。”张逸最后说。

原文 http://soft.zhiding.cn/software_zone/2019/1224/3123732.shtml

正文到此结束