深入实践 DDD：以 DSL 驱动复杂软件开发_杨捷锋著_9787111677710

本书是拥有二十年商业软件开发经验及十年技术管理经验的资深技术专家呕心沥血之作，也是目前市场上少有的阐述如何通过使用领域专用语言（DSL）实现领域驱动设计（DDD）的图书。

书中首先带领读者重温DDD在战术设计层面及战略设计层面上的部分重要概念，并简要介绍了自DDD社区兴起的一些软件架构模式。然后阐述如何设计一门DDD原生的DSL，包括这个DSL的规范支持哪些特性、如何帮助团队描述领域模型的方方面面、这些特性的选择基于何种考量等。

然后在此基础上详细讲解了如何使用技术工具将描述领域模型的DSL文档直接转化为可以工作的软件代码，在这个过程中结合诸多来自商业软件开发工作中的真实案例，展示并分析了大量的关键代码，让读者可以深入地了解制造那些基于DSL的DDD技术工具的秘密。

之后讲述了一些建模案例，并探讨了一些与DDD相关的其他话题，对读者开拓技术思维、更深刻地理解DDD有所助益。

【为什么要写这本书】

2004 年，DDD（领域驱动设计）这一软件开发的方法与愿景经由建模专家 Eric Evans 的经典著作Domain-Driven Design: Tackling Complexity in the Heart of Software 正式面世，当即获得了广泛关注和高度评价。16 年过去了，我在网上看到越来越多关于 DDD的文章和讨论。为什么我们现在还不停地讨论 DDD？为什么DDD仍然如此重要？

在商业组织中，主张“技术为业务服务”的企业总可以在理论上立于不败之地。诚然，DDD主张在软件项目中把领域本身作为关注的焦点（换句话说就是技术人员要懂业务）符合这种思想，但真正难能可贵的是，DDD提供了切实可行的应对软件核心复杂性的方法。

实践证明，DDD 提出的方法不仅行之有效，而且历久弥新。关于这一点，我想从当今 IT 业界的热词“云原生”“中台”“产业互联网”说起。

什么是云原生？云原生计算基金会（Cloud Native Computing Foundation，CNCF）对云原生的定义是：

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。

而阿里云发布的《云原生架构白皮书》对云原生架构的定义是：

从技术的角度看，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

看了这些定义，你是否还是觉得迷惑？打开CNCF的“landscape”页面——里面有很多的项目和成员，难怪有人说云原生是一个“营销词语”。在这个页面中，在 Members（成员）这个标签页的左边，Serverless 独占了一个标签页，十分显眼。

广泛认同的Serverless 架构是指这样的应用设计：与第三方的后端即服务（Backend as a Service，BaaS）交互；在函数即服务（Function as a Service，FaaS）平台上运行函数式业务代码，一般来说，它们是在受管理的、临时性的容器中执行的。

虽然新出现的基于容器的 Serverless 平台，比如 Knative，可以运行开发人员使用传统方式开发的应用，但 FaaS 仍然是 Serverless 中最重要、最具代表性的产品形态，因为它让我们以一种不同于传统的方式思考技术架构。

FaaS 中的“Function”就是不依赖特定框架和类库的最纯粹的业务代码——这是真正为业务带来价值的东西。可以说，FaaS在将云应用中的非业务代码部分进行最大化剥离方面做到了极致。我认为它是云原生“皇冠上的明珠”。

不过，大家普遍认为当前FaaS更适合开发事件驱动风格的、处理少数几个事件类型的应用组件，而不适合开发传统的具有很多入口的同步请求/响应风格的应用组件。也就是说，如果你想问：“能不能基于 FaaS 做出一个 SAP ERP？”目前可能大多数人给你的答案会是“NO”。

但是我想给你的答案是“YES”！因为要想达到这个目标，我们需要克服的所有障碍都不属于 FaaS 的固有缺点，而是当前FaaS 的实现缺陷，比如启动延迟、集成测试、调试、交付、监控与观测等方面的问题。

我认为，以 DDD 方法实现的应用可以极大地降低 FaaS 处理这些问题的难度，甚至可以直接忽视某些问题（因为它们对以 DDD 方法实现的应用来说不是问题）。具体而言，我们可以使用 DDD 的聚合概念来切分应用组件，每个聚合一个小组件，它们可以很快地被 FaaS 平台“拉起”。这些高度内聚的小组件是更复杂的应用组件（比如说领域服务）的构造块。我们可以使用兴起于 DDD 社区的 Event Sourcing（事件溯源，ES）模式，保证应用状态的每一次变更都会发布领域事件，并以富含业务语义的事件驱动其他应用组件运行。比如，命令查询职责分离（Command Query Responsibility Segregation，CQRS）模式中的 Denormalizer（去规范化器）组件就可以订阅、消费这些事件，为前端应用构建友好的查询视图——这些都是 DDD 社区在开发严肃的商业软件时一直在做的事情。如果之前你没有接触过聚合、ES、CQRS，也许难以理解上面所说的内容，不过没关系，读完本书，我相信你就清楚了。

再说“中台”这个热词。以我的理解，中台是将可复用的代码抽取到一个平台中，作为大家共用的软件组件，它是服务于前台的规模化创新。中台（这里主要指业务中台）想要好用，必须具备“反映对领域的深度认知”的软件模型，甚至在某种程度上需要“过度设计”，并且绝对有必要维护良好的概念完整性，构建所谓的企业级业务架构——这些都是 DDD 可以大展身手的地方。

关于“产业互联网即将进入黄金时代”的说法，大多是众多传统企业希望借力最新的信息化，特别是互联网工具（即所谓“互联网+”），提升内部效率和对外服务的能力。传统产业中的很多领域概念和业务流程并不一定为普通的开发者所熟知——这与“消费互联网”不同，显然人人都是消费者。所以，传统产业的信息化急需可以快速梳理并深刻地认知领域，以及能构建高质量领域模型的技术人才。DDD 可以说是技术人员升职加薪的“神兵利器”。

我在工作中看到的情况是，越来越多的技术人员在自己的求职简历上写上了“熟悉（或精通）DDD”的描述。确实，Eric Evans 的经典著作以抽象、凝练著称，可谓字字珠玑，甚至很多资深技术人员都不能领悟其中玄妙。所以，我也认同掌握 DDD 是一件足以让技术人员引以为傲的事情。

可以说，DDD 是公认的解决软件核心复杂性的“大杀器”。但是，在软件开发中实践 DDD 是需要付出相当大的成本的。也就是说，大家的普遍看法是：实践 DDD 是一个先苦后甜的过程，一个项目要不要采用DDD，最好先看看它值不值得。

但是一个项目值不值得使用 DDD 有时不好判断。大项目往往是由小项目发展而来的，很多从小项目演化而来的大系统最终变成开发团队的噩梦，噩梦的根源几乎无一例外地在于软件的概念完整性遭到了破坏。而DDD正是维护软件概念完整性的良药。如果在项目中实践 DDD 的成本不高，那么即使是小项目，从一开始就使用 DDD 不是一件很美好的事情吗？

在软件开发项目中实践 DDD 到底有何难处？16 年了，难道在 DDD 实践中碰到的问题我们不能从书本中寻得答案？

目前国内已经出版的DDD相关图书中，除了 Eric Evans 的经典著作之外，还有《实现领域驱动设计》《领域驱动设计精粹》《领域驱动设计模式、原理与实践》等，不过寥寥数本。这与 DDD 的巨大声望很不匹配，这也许说明了一些问题。

实践DDD首先需要面对的一个（也许是最大的）难题是：难以描述的领域模型。

DDD 想要构建的领域模型是什么？按照 Eric Evans 的观点，领域模型不是一幅具体的图，而是那幅图想要传达的思想；不是一个领域专家头脑中的知识，而是那些经过严格组织并进行选择性抽象的知识。

听起来是不是有点玄奥？系统分析师、产品经理到底要拿出什么样的领域模型才能说

“我的工作已经做到位了”？这个模型到底是不是可以实现的？开发人员、测试人员到底有没有理解这个模型？大家的理解是不是一致的？

说到底，一个领域模型要想有用，它必须足够严格。如何使用一种严格的方式描述经过严格组织并进行选择性抽象的知识呢？

问题的答案很自然地指向了 DSL。

其实，Eric Evans 早就意识到了这一点。他曾经在访谈中说：

更多前沿的话题发生在领域专用语言（DSL）领域，我一直深信 DSL 会是领域驱动设计发展的下一大步。现在，还没有一个工具可以真正给我们想要的东西。但是人们在这一领域比过去做了更多的实验，这使我对未来充满了希望。

通过本书，我想要告诉大家的是：在项目中运用 DDD 可以不像大家想象的那么痛苦，DDD 并不是只适用于大项目，使用 DDD 并不一定需要牺牲敏捷性，一切的关键在于 DSL 的运用。

我和我工作过的团队曾经在多个项目中使用 DSL 实现了 DDD 的真正落地。独乐乐不如众乐乐！现在，我想把这些实践经验分享给大家。

【读者对象】

领域模型是一种“思想”，它可以为软件开发的全过程提供指导，所以我相信本书可以为很多人提供帮助：

产品经理与系统分析师。产品经理不仅仅需要保证团队开发的是“正确的软件”，也不应该只是关注软件的界面原型、用户体验，更应该让软件有内涵。迷人的产品不仅需要漂亮的界面和交互，更需要逻辑自洽，功能处处传达出一个思想——优美而深刻的领域模型。在有的团队中，产品经理同时也是系统分析师。作为近十几年来最有影响力的软件分析和设计的方法论，系统分析师有必要了解DDD，从中汲取营养。

架构师。架构师需要根据业务需求提供技术解决方案。DDD 想要构建的领域模型不仅仅是领域业务知识的提炼总结，也包含了对软件设计的考量，可以用于直接指导软件的编码实现。构建这样的模型，需要架构师的积极参与。

开发工程师。开发工程师应该理解领域模型，领域模型应该被忠实地映射到代码实现中。代码中对象的命名、对象之间的关系，都应该与领域模型一致。唯有如此，代码才能具备良好的可读性、可维护性，敏捷 XP 方法的狂热爱好者们所言的“代码即文档”才可能实现。

测试工程师。如今很多测试工程师已经被称为“测试开发工程师”，他们也应该理解领域模型。测试工程师应该像产品经理一样了解软件的设计，甚至应该比产品经理更深刻地理解领域模型面向软件设计所做的考量。实例化需求的自动化测试（或者说行为驱动测试）应该基于领域模型，而非基于 UI/UE 来构建，因为用户界面以及用户交互是易变的，而领域模型相对来说稳定得多。

项目经理。项目经理是负责“正确开发软件”的人。如果不深刻理解领域，不知道如何抓住领域模型中的关键点，会很难评估任务工作量的大小以及应该在何处投入足够的资源，甚至无法判断项目的实际进度。

高校研究生以及其他有志于从事 IT 行业的人。

【如何阅读本书】

本书的第一部分会带领读者从战术层面以及战略层面重温领域驱动设计的重要概念，然后进一步阐述Eric Evans经典著作中没有显式提出的或者被太多人忽略的但我认为对 DDD 落地非常重要的若干概念，同时简要介绍从 DDD 社区兴起的一些软件架构模式。通过第一部分，读者可以更完整、更深刻地掌握 DDD 的知识体系。

第二部分阐述如何设计一种DDD的DSL，包括这个DSL的规范（Specification）支持哪些特性、如何帮助团队描述领域模型的方方面面、这些特性的选择基于何种考量等。

这种领域专用语言需要一个名字，我们总不能一直说“我设计的 DDD 的 DSL”吧，于是我给它起了一个名字：DDDML。我认为这是一个很棒的名字。其实这种语言叫什么并不太重要，重要的是它可以用一种足够严格的方式描述领域模型。我认为目前它在简单与复杂之间取得了不错的平衡。当然，其中还有不小改进的空间。比如，我很乐意让它支持更多像“账务模式”这样的分析模式。

第三部分介绍如何将“思想照进实现”——通过使用工具将描述领域模型的 DSL 文档变成可以运行的软件。这个过程涉及大量的技术工具（工具链）的设计与实现。只有将这些技术工具——比如从 DSL 自动生成应用的源代码的模板——实现出来，才能减轻开发人员实践 DDD 的负担，进而提升而不是降低软件团队的生产效率。本部分会介绍这些技术工具设计与实现的细节。

我和我的同事把自制的 DDDML 工具链称为 DDDML Tools。出于商业原因，我无法展示这些工具的源代码，但是会详尽地展示这些工具运行的结果——主要是由工具生成的应用的源代码。这些源代码可能经过一些简化，但是与我们在生产系统上运行的代码十分接近，完全可以说明问题。

读完全书，你将发现其实我们已经全无秘密。你会熟知 DDDML 的规范，见到工具运行的结果，你几乎可以马上动手制造自己的 DDDML 工具。其实设计 DDDML 的规范才是整件事情（使用 DSL 实现领域驱动设计）中最难的部分，制作工具不是。虽然想要复刻我们已经做过的所有工具确实需要相当大的工作量，但也仅仅是工作量而已。

幸运的是，你并不需要制造整条 DDDML 的工具链才可以享受使用 DSL 的乐趣。比如，你可以先写一些模板，生成一些持久对象（Persistant Object），它们无非是一些简单的 Java 对象（Plain Ordinary Java Object，POJO），然后再生成一些 O/R Mapping XML，就可以马上使用 JPA/Hibernate 来实现应用的 DAL（数据访问层）了。如果你再生成 Repository，那就更漂亮啦！

第四部分讲述的是一些建模案例以及其他与 DDD 相关的话题。领域模型是一种思想，DSL 是一种工具，但是如何运用、结果如何，因人而异。我希望通过轻松的漫谈和随想，将我的一点DDD应用经验分享给大家。

你还可能感兴趣

我要评论