(特价书)深入实践DDD：以DSL驱动复杂软件开发
领域驱动设计里程碑之作，资深技术专家兼技术管理者二十年工作经验结晶
深度解读DDD思想，揭示使用DSL实现DDD快速落地的方法与技巧，缓解复杂软件开发之痛
深度解读DDD思想，揭示使用DSL实现DDD快速落地的方法与技巧，缓解复杂软件开发之痛
基本信息
编辑推荐
领域驱动设计里程碑之作，资深技术专家兼技术管理者二十年工作经验结晶
深度解读DDD思想，揭示使用DSL实现DDD快速落地的方法与技巧，缓解复杂软件开发之痛
内容简介
书籍
计算机书籍
本书是拥有二十年商业软件开发经验及十年技术管理经验的资深技术专家呕心沥血之作，也是目前市场上少有的阐述如何通过使用领域专用语言（DSL）实现领域驱动设计（DDD）的图书。
书中首先带领读者重温DDD在战术设计层面及战略设计层面上的部分重要概念，并简要介绍了自DDD社区兴起的一些软件架构模式。然后阐述如何设计一门DDD原生的DSL，包括这个DSL的规范支持哪些特性、如何帮助团队描述领域模型的方方面面、这些特性的选择基于何种考量等。然后在此基础上详细讲解了如何使用技术工具将描述领域模型的DSL文档直接转化为可以工作的软件代码，在这个过程中结合诸多来自商业软件开发工作中的真实案例，展示并分析了大量的关键代码，让读者可以深入地了解制造那些基于DSL的DDD技术工具的秘密。之后讲述了一些建模案例，并探讨了一些与DDD相关的其他话题，对读者开拓技术思维、更深刻地理解DDD有所助益。
计算机书籍
本书是拥有二十年商业软件开发经验及十年技术管理经验的资深技术专家呕心沥血之作，也是目前市场上少有的阐述如何通过使用领域专用语言（DSL）实现领域驱动设计（DDD）的图书。
书中首先带领读者重温DDD在战术设计层面及战略设计层面上的部分重要概念，并简要介绍了自DDD社区兴起的一些软件架构模式。然后阐述如何设计一门DDD原生的DSL，包括这个DSL的规范支持哪些特性、如何帮助团队描述领域模型的方方面面、这些特性的选择基于何种考量等。然后在此基础上详细讲解了如何使用技术工具将描述领域模型的DSL文档直接转化为可以工作的软件代码，在这个过程中结合诸多来自商业软件开发工作中的真实案例，展示并分析了大量的关键代码，让读者可以深入地了解制造那些基于DSL的DDD技术工具的秘密。之后讲述了一些建模案例，并探讨了一些与DDD相关的其他话题，对读者开拓技术思维、更深刻地理解DDD有所助益。
作译者
杨捷锋 著：杨捷锋，曾就职于南开戈德集团、普天集团、通路快建等公司。曾作为独立技术顾问为海尔集团、沈阳飞机工业集团、上广电NEC、天马微电子等企业提供软件开发与技术咨询服务。目前在一家电商创业公司担任技术负责人。有多个大型企业应用软件的分析建模经验，以及大型开发框架（ORM、IoC等）的架构经验。多年来一直未脱离软件开发一线工作，近年来自认为对软件系统分析、数据建模、领域驱动设计、项目管理略有心得。
目录
前 言
第一部分 概念
第1章 DDD 的关键概念 2
1.1 自顶而下、逐步求精 3
1.1.1 DDD开创全新分析流派 3
1.1.2 什么是软件的核心复杂性 4
1.2 什么是领域模型 4
1.3 战术层面的关键概念 6
1.3.1 实体 6
1.3.2 值对象 6
1.3.3 聚合与聚合根、聚合内部实体 7
1.3.4 聚合的整体与局部 9
1.3.5 聚合是数据修改的单元 9
1.3.6 聚合分析是“拆分”的基础 10
1.3.7 服务 12
1.4 战略层面的关键概念 13
1.4.1 限界上下文 13
1.4.2 限界上下文与微服务 14
1.4.3 防腐层 15
1.4.4 统一语言 18
第一部分 概念
第1章 DDD 的关键概念 2
1.1 自顶而下、逐步求精 3
1.1.1 DDD开创全新分析流派 3
1.1.2 什么是软件的核心复杂性 4
1.2 什么是领域模型 4
1.3 战术层面的关键概念 6
1.3.1 实体 6
1.3.2 值对象 6
1.3.3 聚合与聚合根、聚合内部实体 7
1.3.4 聚合的整体与局部 9
1.3.5 聚合是数据修改的单元 9
1.3.6 聚合分析是“拆分”的基础 10
1.3.7 服务 12
1.4 战略层面的关键概念 13
1.4.1 限界上下文 13
1.4.2 限界上下文与微服务 14
1.4.3 防腐层 15
1.4.4 统一语言 18
前言
为什么要写这本书
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，最好先看看它值不值得。
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以及DSL——以“领域驱动设计”的方法构造 DDD 风格的领域模型，并以DSL来描述它们。作者以近20年的编码经验练就的深厚功力，在书中写下DDD实践的思考及建议，十分精彩，令人击节。
—— 郝培强（Tinyfool） 英语轻松读创始人
技术的本质是为了业务创新或者解决业务中的各种问题。领域驱动设计（DDD）是架构设计中的经典思想，经典不会过时。杨捷锋的DSL实践给我们带来了DDD领域的更多经验与思考。
—— 杨卫华（Tim Yang） Westar区块链实验室创始人、中国计算机学会TF架构SIG主席
传统企业的数字化不仅需要推动互联网发展的高并发、大数据等新技术，更需要构建领域模型，以支持复杂的企业业务的持续演进。如何才能实现？良方是DDD。但是，技术人员没有一定的经验，运用DDD时很容易犯错误。本书从道、术、工具等多个层次阐述DDD。需要举例说明时，作者不满足于使用简单的例子，而是拿出工作中碰到的经典案例来讲解，更有结合DDD对软件SaaS化及PaaS化的思考。本书值得借鉴与研读。
—— 刘建蓝图移动首席架构师、前蓝信技术合伙人
为了避免业务突变而燃尽利润，我们需要构建对领域的深度认知模型。但模型描述标准化、代码生成等难题多年来横亘在DDD前进的道路上。Eric Evans早就说过，DSL会是DDD的下一大步，现在我们终于有了DDDML！基于DDDML的解决方案已经在电商行业实践，现在更剑指构建云端FaaS平台的“小目标”——最具有业务价值的代码应该用简单的函数来写。诸多细分领域的DSL（如BPMN 2.0）已然大获成功，相信DDDML亦当如此。
—— 胡天成原PFU（富士通集团）技术顾问
领域驱动设计是个美妙的愿景。长期以来，虽有不少技术管理者对各种先进的概念和方法论充满激情，但像作者这样多年在工作中坚持实践领域驱动设计的，并不多见。作者早年主要为海尔、宝洁、沈飞、朗讯等传统企业提供技术服务，近几年又投身于互联网行业，经验丰富。本书不囿于管理者的视角，更从工程师的角度直指领域驱动设计落地的关键，书中充满操作性极强的建议，直至代码级的剖析讲解，值得拥有。
—— 杨彬海贝易通董事长、前朗讯研发总监
—— 郝培强（Tinyfool） 英语轻松读创始人
技术的本质是为了业务创新或者解决业务中的各种问题。领域驱动设计（DDD）是架构设计中的经典思想，经典不会过时。杨捷锋的DSL实践给我们带来了DDD领域的更多经验与思考。
—— 杨卫华（Tim Yang） Westar区块链实验室创始人、中国计算机学会TF架构SIG主席
传统企业的数字化不仅需要推动互联网发展的高并发、大数据等新技术，更需要构建领域模型，以支持复杂的企业业务的持续演进。如何才能实现？良方是DDD。但是，技术人员没有一定的经验，运用DDD时很容易犯错误。本书从道、术、工具等多个层次阐述DDD。需要举例说明时，作者不满足于使用简单的例子，而是拿出工作中碰到的经典案例来讲解，更有结合DDD对软件SaaS化及PaaS化的思考。本书值得借鉴与研读。
—— 刘建蓝图移动首席架构师、前蓝信技术合伙人
为了避免业务突变而燃尽利润，我们需要构建对领域的深度认知模型。但模型描述标准化、代码生成等难题多年来横亘在DDD前进的道路上。Eric Evans早就说过，DSL会是DDD的下一大步，现在我们终于有了DDDML！基于DDDML的解决方案已经在电商行业实践，现在更剑指构建云端FaaS平台的“小目标”——最具有业务价值的代码应该用简单的函数来写。诸多细分领域的DSL（如BPMN 2.0）已然大获成功，相信DDDML亦当如此。
—— 胡天成原PFU（富士通集团）技术顾问
领域驱动设计是个美妙的愿景。长期以来，虽有不少技术管理者对各种先进的概念和方法论充满激情，但像作者这样多年在工作中坚持实践领域驱动设计的，并不多见。作者早年主要为海尔、宝洁、沈飞、朗讯等传统企业提供技术服务，近几年又投身于互联网行业，经验丰富。本书不囿于管理者的视角，更从工程师的角度直指领域驱动设计落地的关键，书中充满操作性极强的建议，直至代码级的剖析讲解，值得拥有。
—— 杨彬海贝易通董事长、前朗讯研发总监
