DDD是什么2003 年Eric Evans 写了《领域驱动设计软件核心复杂性应对之道》一书正式提出了这种方法。领域驱动设计的英文是 Domain-Driven Design简称 DDD。按照作者自己的说法“DDD 是一种开发复杂软件的方法”。我们把作者的原话做一个扩展“DDD 是一种开发复杂软件的系统化的方法学和思想”通俗的说就是提供了一套复杂软件开发的标准步骤。下面我们把上面的话拆解一下什么是方法学方法学Methodology是一门学科指在特定领域进行研究或活动时所采用的一套方法、规则和原则的体系。这里的方法学指的是面向对象的方法学如果你的Java 代码写得特别溜可以说掌握了面向对象的编程方法如果你很熟悉面向对象的设计原则掌握很多设计模式可以说你懂面向对象的设计方法如果你能为业务概念构建领域模型那么你就懂了面向对象的分析方法面向对象的分析、设计、编码三种方法融会贯通成为一个有机的整体这个叫面向对象的方法学。其中面向对象的分析方法或者说领域建模的方法正是DDD的重点。什么是系统化系统化方法的作用在于提供了一套相对容易的步骤能够使我们这些中等智商的人也能做到原来高智商的人才能做到的事情从而让你能够省出时间和脑力来探索更复杂的问题。DDD中蕴涵了哪些思想归纳一下大概有构建知识、分而治之、抓大放小、统一语言、抽象化、可视化、协作以及演进等等。DDD 是通过总结了一套系统化的方法学能够把这些大词落地。DDD是怎么出现的按照作者在原书中的说法DDD 是来自面向对象的方法学和敏捷软件开发。DDD 对它们进行了总结和提炼使之更容易学习和实践。但是面向对象方法学从 80 年代兴起到了2000 年左右已经成熟。既然有了面向对象为什么还要有DDD 呢这是因为传统的面向对象方法学存在一些问题。传统面向对象方法学的问题早期面向对象的成功主要是在几个特定的领域比如计算机语言、图形用户界面、办公自动化软件等等但在企业应用方面还没有取得成功。所谓企业应用包括像银行的贷款系统、保险公司的理赔系统、电信公司的计费系统等等。那个时候的面向对象方法学还不能很好地应用于企业应用大体上有以下几个原因。开发人员只重技术不重业务也就是技术驱动业务。企业应用是用来解决业务问题的但很多开发人员把主要精力放到技术的研究上比如语言、框架、工具等等。以为把技术学会了自然就能把系统开发好。同时重技术、不重业务的思想造成了业务和技术人员之间难以相互理解技术人员难以真正满足业务需求。领域建模落地难度高。面向对象方法学主要是围绕领域建模开展的。领域建模是一种“手艺”。凡是手艺都不是看看书、学学理论就能掌握的而是要经过实践中的磨炼学习成本自然就高。早期面向对象方法学主要考虑的是建模技术很少考虑协作问题。历史上很多伟大的软件开始时都是个人作品比如 UNIX 和 C 语言。作者在一开始是写给自己用的所以并不存在协作问题。但是企业应用则不同多数都是团队作战。即使只有一线开发人员也免不了和需求方打交道。所以协作变得很重要。难以适应变化。企业应用的需求往往变化频繁很多变化根本无法预料。传统的面向对象方法学也很少讨论怎样应对变化的需求。DDD如何落地企业应用针对以上四个问题DDD是这么解决的把开发者从只重技术的弯路上拉回来也就是用领域来驱动设计。从“领域驱动设计”这个名字就可以看出“领域”指的就是软件系统要解决的业务问题也可以叫“业务领域”。用领域来驱动设计就是说要从业务出发进行系统的设计。总结出了一套围绕领域建模进行软件开发的模式。要搞清业务就要学会领域建模。为此DDD对面向对象方法学和敏捷软件开发方法进行了提炼总结出了一套围绕领域建模进行软件开发的模式一共有四十多个。最基础的模式包括模型驱动设计实体、值对象。强调业务人员和技术人员一起协作进行领域建模在这个过程中提炼领域知识。和协作密切相关的模式有通用语言、模型驱动设计、限界上下文。提出柔性设计概念。软件设计之初仅进行必要的设计而非过度设计随着业务变化仅对变化频繁的部分进行迭代使其越来越灵活。也就是说模型中扩展性高的部分是自然演进形成的这个过程就是柔性设计它能够避免过度设计。从上面看DDD提炼了一套更容易掌握的原则、模式和实践能够解决企业应用开发过程中的各种问题。既然DDD这么好为什么之前不火《领域驱动设计》这本书其实是 2003 年写的到现在已经20多年了。但直到2020年左右DDD才真正开始普及起来。主要有两个原因使用DDD的必要性不强。一方面很多企业软件不太复杂而复杂软件的迭代也不像现在这样频繁另一方面当时的新兴产业例如互联网还处在跑马圈地、野蛮生长的阶段。这时关注的是系统快速上线抢占市场至于软件质量好不好容不容易维护暂时不是考虑的重点。DDD 普及的一些前提条件也还没准备好。首先是敏捷软件开发刚刚出现不久还不普及。如果没有迭代开发、持续重构、测试驱动、持续集成等敏捷实践的支持构建良好的领域模型并在代码上落地是很困难的。其次是配套的开发框架还不成熟。那时 J2EE 还被认为是企业应用事实上的标准而基于这种框架开发程序是很难和 DDD 的领域模型相衔接的。2004 年Spring 发布了 1.0 版从技术上基本解决了 EJB 的问题理论上可以比较好地支持 DDD。然而 Spring 的真正普及还要假以时日。DDD为什么近几年又火了呢数字化时代的到来使 DDD 变得非常有必要。数字化时代技术逐渐成为企业核心竞争力的主要因素无论业务还是系统都变得更加复杂。因此如何将业务和技术融为一体就成了很多企业的主要问题而这正是 DDD 的主要优势。行业竞争的加剧也要求系统具有更好的用户体验、更高的质量、更快地满足变化的需求。这些问题很难解决必须引入系统化的方法。另外云计算、微服务等新技术架构的产生也需要方法学的支持。DDD 普及的道路已经铺好这项技术逐渐变得可行。现在敏捷软件开发已经普及。迭代、演进、协作等思想已经深入人心。Spring boot 等轻量级框架已经得到广泛使用这些框架支持了领域模型与具体技术的关注点分离使开发人员从技术细节中解放出来将更多的精力投入到领域逻辑本身的分析和设计。支持DDD落地的相关架构实践也已经研究得比较透彻比如整洁架构、事件驱动架构以及 CQRS 等等。DDD 本身也在不断完善比如补充了像领域事件等新的模式出现了事件风暴等新的实践。DDD的适用场景开发中哪些场景推荐使用DDD呢业务复杂的企业应用。当业务过于复杂时经常出现业务人员和开发人员的理解不一致、沟通效率低的情况或者经常要用一段加了很多限定词的话来描述一个业务数据。这些时候就有必要采用DDD进行领域建模形成一些业务概念并与业务达成一致来提升后续沟通效率。迭代成本高的系统。在系统前期因为业务迭代速度快经常出现补丁式的代码或者定制化代码使得系统的扩展性和可维护性下降维护成本越来越高。这个时候同样也可以通过领域建模将业务过程拆分为多个领域并明确各领域边界。后续业务迭代时在对应领域内进行升级将影响范围降到最小。有重构诉求的系统。因为各种各样的问题吧有些系统的架构和代码已经严重腐化了希望通过重构来提高代码质量和可维护性但不知道往哪个方向重构怎么在重构过程中降低风险并且兼顾业务需求呢同样可以通过领域拆分划分子领域边界。采用每次重构一个子领域的方式逐步完成项目整体重构。DDD的学习路径学习DDD要经过三个阶段阶段一夯实基础通过这个阶段你可以打通一个“需求 - 模型 - 代码”的最小闭环对 DDD设计及落地过程有一个初步的感觉。首先学习“事件风暴”方法梳理行为需求同时介绍“统一语言”。其次实操DDD 的核心技能“领域建模”引入实体、关联、模块几个重要的模式。最后进行模型的实现包括数据库设计、编码。阶段二渐入佳境这个阶段学习一些高级技能。首先会从理论、模型和编码层面学习“聚合”。其次学习值对象包括值对象的本质和优点并解决值对象在建模和编程上的一些具体问题。最后学习一个重要的建模技巧——泛化这是领域建模由初级走向中、高级的关键技能。阶段三更进一步首先介绍“限界上下文”模式。其次学习事件驱动和 CQRS两个架构模式。最后会介绍实践落地的关键要点包括DDD 切入点的选择遗留系统的改造等等几个思考题Q1为什么领域建模需要经常迭代而非一步到位呢我觉得主要有两部分原因人对一个业务领域的理解是逐步加深的过程而非一步到位所以领域模型也是逐步迭代的。业务是不断变化的领域模型为了适应业务的变化也要不断迭代。Q2有人说DDD的目的就是为了开发微服务你觉得呢DDD 是一种设计思想方法论适用于任何复杂业务系统可以用在单体、模块化、也可以用在微服务里。它最开始被提出核心目标是解决复杂业务软件的建模问题——让代码能够准确表达业务意图。Eric Evans 在 2003 年提出微服务是一种架构风格可以用 DDD 指导拆分也可以不用。微服务更多是技术架构层面的拆分策略解决的是组织协作、部署独立、弹性伸缩、技术异构等工程化问题重点围绕如何拆、拆多小这些工程实践。Martin Fowler 和 James Lewis 在2014年推广微服务因为 DDD 的限界上下文和微服务的服务边界在划分思路上一致都是强调高内聚、低耦合。所以可以用 DDD 的思路去指导微服务的拆分。DDD 是手段微服务是可能的结果之一但不是唯一目的。写在最后一个新的设计思想的出现及流行一定有其必要性DDD也不例外。随着经济的发展业务日益复杂对系统可维护性及扩展性的诉求必然会提高DDD就能很好的解决这个问题。通过事件风暴方法将业务过程拆分为多个业务领域并划定领域边界将产生的概念与产研测、业务、运维等形成共识对于后续的沟通及业务的发展都有极大的帮助。学习资料本系列为极客时间的《手把手教你落地 DDD》学习笔记。《领域驱动设计软件核心复杂性应对之道》电子版https://zhongjinggz.github.io/ddd-reference-cn/#/README