用DDD(领域驱动设计)和ADT(代数数据类型)提升代码质量

很多开发者都有一个迷思，认为项目里的代码质量和可维护性的持续下降，主要根源在于时间紧迫、需求变动频繁。如果产品需求更加明确，并给予足够的开发时间，开发团队可以长期保证代码质量和可维护性。

今天介绍的 DDD(领域驱动设计) 和 ADT(代数数据类型) 的模型，给出了另一部分的答案：代码质量持续下降，开发团队也要负主要责任。

如果没有采用更合理的开发模型，项目的代码质量将随着时间和复杂度的增加而急剧下降。再明确的产品需求，再多的开发时间，也很难阻止代码库的腐坏。

由于 DDD 和 ADT 都是很大的主题。很难在一篇技术文章中充分展开。因此，本文主要是简要地介绍它们之间的关系以及背后的思想，希望能够带给大家一些启发。感兴趣的同学，后续可以查阅更深入的材料。

主要内容分成以下几个部分：

  1. 代码质量的评估方式
  2. DDD 的概念与定义
  3. ADT 的概念的定义
  4. 案例：用 DDD + ADT 做数据建模
  5. 案例：用 DDD + ADT 做流程建模
  6. 总结

1、代码质量的评估方式

不管做哪种提升和优化，最关键的起始步骤总是寻找衡量的标准和方法。提升代码质量也不例外。

1.1、代码质量的评估标准

上述指标是在一个相对宏观的层面评估代码，偏向定性指标。

给定两段代码，开发可以判断出哪一个可拓展性更好，但具体好多少，却不容易有一致的判断。特别是可读性这个指标，非常依赖开发者的经验和主观偏好。

有一些定量指标，比如一些 Lint 规则、循环引用检测等，对提升代码质量也有帮助。但这类定量指标的不足之处在于，它们在一个非常微观的层面做代码评估，并不关心代码要解决的问题是什么。

这类定量指标，容易失效甚至带来反效果。对处理具体问题的帮助也有限，主要服务于统一代码风格、约束写法、规避常见反模式。

我们希望有一种评估标准，既能在宏观定性层面帮助我们考虑问题，又能在微观定量层面帮助我们解决问题。

1.2、几种代码质量的提升方法

有很多编程原则可以提升代码质量，其中最著名的两个或许是 SOLID 和设计模式 (Design Patterns)，它们已经出现至少二三十年，在今天依然被开发者们津津乐道。

单一职责、开闭原则、接口分离原则、观察者模式、订阅模式、解释器模式、装饰器模式、低耦合、高内聚…… 这些词汇在程序员群体里耳熟能详，历久弥新。

不过：

大家发现了编程原则背后的认知偏差——相关性不等于因果。

从高质量的代码中提炼的特征，跟代码质量之间有一定的相关性，但不意味着是因果关系：高质量代码都有某些特征，不意味着有某些特征的代码就是高质量的代码。

如上图所示，假设最大的圈是整个代码宇宙，里面的小绿圈是优质代码，绿圈之外则是低质量代码，黄圈则是符合 SOLID 等编程原则的代码。

我们可以看到，在这种关系中：

因此，盲目地在代码库里推广某种代码特征，往往会带来反效果。

1.3、当前代码指南的不足之处

目前的代码质量评估模型和代码指南，仍有以下几个不足之处：

与上面的不足相对的，我们可能想要的是：

优雅的代码，不只是某种写法或者编程技巧，而是更深入地认识问题的本质后，所带来的副产品。

因此，代码怎么写，怎么写出高质量的代码，离不开提高对问题的理解水平。

编写高质量代码的指导模型，不能只关注代码怎么写的这一阶段，还需要有怎么认识问题的前置阶段。

2、DDD 的概念与定义

DDD（领域驱动设计）是 2003 年开始流行的一种开发模式，它的含义非常广。

领域驱动设计，不只是关注代码怎么写，更关注写代码之前的活动，比如产研流程和协作。

偏向写代码的 DDD，叫战术型 DDD；偏向产研流程和协作的 DDD，叫战略性 DDD。但它们的核心是一致的，后面我们会展开讨论。在此之前，让我们看看，朴素的产研模式。

2.1、朴素产研模型：需求驱动设计

我们可以把这种模式称之为——需求驱动设计。

它的一般过程是，产品经理跟业务同事们沟通以及做市场调研分析，挖掘出产品需求，并制作成产品需求文档（PRD），然后开发根据 PRD 中的需求描述，提供代码实现。

在这种模式中，业务们有自己的业务用语，产品们也有自己的产品用语，开发工程师有自己的技术用语。它们之间有一定的关联，但并不足够紧密和强烈。

不会有人要求开发写代码时一定要用业务用语里的名词和概念。

从领域驱动设计的角度看，这个模式的问题就在于，不像一个团队，而是三个团队。

开发之间主要通过技术用语交流，消费的是上游产品用语的材料。开发很难确定自己接到的需求，是不是业务真正的需求，自己理解的逻辑，跟业务同事理解的是不是一样的。

在这种情况下，开发会强烈希望需求是尽可能真实的、明确的、稳定的。开发会很反感上游交付的是不确定的需求，代码频繁修改。

当遇到跟产品难以通过沟通达成共识的时候，开发会想要直接跟业务沟通，了解业务的一手需求。

在需求驱动设计的模式里，需求的生命周期很短，基本上需求发布上线不久之后，它们就被遗弃了。很少有产品团队能够始终维护完整的产品文档，跟线上的功能一一对应。往往在产品经理换人之后，需要通过读代码来反推产品逻辑。

这里问题就来了，代码是在技术用语的上下文里编写的，它们其实不容易反映产品里的概念，更加不用说业务概念了。

2.2、领域驱动设计的核心思想与关键过程

领域驱动设计的产研模型里，所凸显的重点是——知识。

如果说，需求是关于 How、要怎么做的，知识就是关于 What 和 Why 的，是什么，为什么。

知识和需求，也不冲突。需求就来自知识。

我们也可以把领域驱动设计，叫做——知识驱动开发。它强调的是，从领域知识到代码实现的过程。

不管是战术型 DDD，还是战略性 DDD，或者其它 DDD 的方面，都围绕知识驱动开发这个核心思想展开。把握住了核心，不容易被 DDD 里诸多复杂概念所迷惑。

领域驱动设计的关键过程，是解决团队中不同岗位和角色之间，交流语言不统一的问题。

上图中的领域专家，大部分情况下指业务人员。但也不尽然如此，DDD 里的领域专家，不是一个岗位，而是一个角色。在特定领域里更专业、懂得更多、更权威，他就成了领域专家的角色。

通过构建团队统一用语，开发可以更为确定产品需求是真需求，自己理解的逻辑，跟领域专家或业务同事们的理解是一致的。因为大家都用同一套词汇，相同的定义，彼此有共识基础。

领域驱动设计和需求驱动设计的差异，可以从它们的会议形式上管中窥豹。

需求驱动设计的会议，通常是产品经理将已完稿的 PRD 进行讲解，前置的知识提取、梳理和定义等阶段，大体已经成形。

而领域驱动设计的会议，有所不同。如上图是一种被称之为事件风暴 (Event Storming) 的会议模式。领域专家、开发工程师等多个角色共同在一块长条白板上，基于时间轴和事件进行领域知识的表达和建构。

在这个过程中，业务领域里的实体、事件、流程、关系等诸多概念被提出、定义和明确，在场所有人都对此有共识。每一次事件风暴会议形成的词汇和术语，都作为下一次会议或者工作交流中的统一用语和语料。

2.3、小结

3、ADT 的概念的定义

采用领域驱动设计的战略部分，可以优化团队协作模式，确保从知识到代码的过程中，知识部分是基于良好定义的共识所得到的，需求因而更有概率是真实需求。

而领域驱动设计的战术部分，则是反过来：从代码到知识。

简单地说，DDD 要求代码中必须使用 “团队统一用语” 里的词汇和概念。

代码应当忠诚地反映领域知识。代码里的变量名、方法名以及核心逻辑，应当反映领域知识里的定义。代码编写不是随意的，而是每一个掌握了领域知识的开发者，都能写出大体一致的代码，而非五花八门的多样性实现。

如果说需求驱动设计，要求代码满足产品需求的外延定义。即在输入 / 输出的功能层面满足产品需求。

那么领域驱动设计，要求代码满足领域知识的内涵定义。不仅在输入 / 输出的黑盒层面满足功能要求，在代码细节的白盒层面也满足领域知识的定义。

这要求我们必须知道，如何把领域知识翻译成代码实现。

代数数据类型 (ADT, Algebraic Data Types) 是支撑上述需求的关键编程特性。

3.1、领域和领域知识的定义

首先我们需要精确定义什么是领域（Domain），什么是领域知识 (Domain Knowledge)。

所有领域，都由一些关键概念节点构成，领域知识则是这些概念节点之间的关系的定义，表达为逻辑上的真命题。

作为命题的领域知识，在产品需求里被表述为一系列领域规则 / 业务规则。

产研团队常说的业务逻辑，可以被翻译为更严格的数学逻辑的表达形式。

3.2、柯里 - 霍华德同构

用代码表达领域知识的原理——柯里 - 霍华德同构 (Curry–Howard isomorphism)。

柯里 - 霍华德同构，给出了将命题翻译为类型的方式，它提供了将领域知识翻译成代码实现的通用方式。

特别是对应着 And 关系的 Product Type，和对应着 Or 关系的 Sum Type，它们两个构成了代数数据类型 (ADT)。

后续我们将演示，如何用 Product Type 和 Sum Type 做数据建模和流程建模，跟领域知识 / 业务规则一一对应起来。

值得一提的是，在柯里 - 霍华德同构中，真命题和假命题，并不是对应着 Boolean Type 的 true 和 false。而是类型所允许的值的数量 (size)，0 个值为假命题，至少 1 个值为真命题。

也就是说，所有能运行的代码在这个意义上都是真命题，抛错等行为才意味着碰到程序的假命题。

3.3、Bug 的定义和高质量代码的判别标准

通过柯里 - 霍华德同构，Bug 的定义，以及高质量的代码的判别标准，也有了更清晰的陈述。

在将领域逻辑翻译成代码逻辑的过程中，如果发生匹配错乱，领域里的命题跟代码里的命题不一致，Bug 就发生了。

所有能跑的程序都是程序意义上的真命题，但不意味着是业务意义上的真命题，这种不匹配被称之为非法状态（Illegal-States）、非法操作（Illegal-Operations）或不预期的行为 (Unexpected Behaviors)，是应当被避免的。

所谓的高质量代码，与 Bug 的定义相反，领域里的命题跟代码里的命题一致。

这意味着，代码里运行着的程序和数据，需要都是有业务意义的。更少的非法状态、非法操作和不预期的行为。

3.4、类型论 (Type Theory) 的基础知识

In type theory, every term has a type. A term and its type are often written together as "term : type".

类型论和集合论在某些方面很类似，它们都是对合集 (collection) 的不同建模。在这里，合集 (collection) 是指一堆事物的聚合。

在类型论中，事物被称之为项 (term)，它有且只有一个类型 (type)。而类型 (type)，可以有零到任意多个项 (term)。其中一些典型的类型，列举如下：

如上，我们例举了一些基础类型，它们的 term 的数量也标记了出来，跟集合论里的元素数量类似。

3.5、代数数据类型 (Algebraic Data Types)

In type theory, an algebraic data type is a kind of composite type, i.e., a type formed by combining other types.

所谓的代数数据类型 (ADT)，指的是多个类型组合成新的类型的方式，这些组合方式拥有一些代数特征。

由前面的柯里 - 霍华德同构，我们知道，逻辑的 Or，对应的类型是 Sum type，表达的是互斥的、或的关系。而逻辑的 And，对应的类型是 Product type，表达的是并存的，与的关系。

其中，Sum 含义是相加，Product 是指相乘，描述的是 Sum type 和 Product type 的项的数量，跟它的组成部分的类型的项数量的关系。

如上，size(..) 函数可以获取特定 type 所允许的 term 的数量。

那么，Sum type 对应的就是加法，因为 A 和 B 在这里是 “或” 的关系，是互斥的，不会一起出现，所以要么 A，要么 B。那所有可能性就是 A 的可能数量，加上 B 的可能数量。

// sum types
type Value = string | number;

const a: Value = 'John';
const b: Value = 70;

而 Product type 对应的是乘法，因为 A 和 B 在这里是 “与” 的关系，是并存的，会一起出现，所以既有 A，也有 B。那就进入 A 和 B 的组合可能性，每一个 A 都能搭配所有 B，有 A 个 B，即 A * B。

// product types
type Person = { name: string; age: number };
// type Person = { name: string } & { age: number }

const person: Person = { name: 'John', age: 70 };

如上，对象的字段之间是 product type 关系。product type 不是具体的某个类型，而是一系列类型，只要它们背后的 size 关系是乘法相关的。同理，sum type 指的是那些背后的 size 关系是加法相关的类型。

只需要了解到目前的程度，代数数据类型 (ADT) 已经可以优化我们的代码质量了。接下来，我们来看看它在数据建模和流程建模上的应用。

4、案例：用 DDD + ADT 做数据建模

假设有以下用户信息的领域规则 (业务定义)：

它们被描述为一组自然语言描述的规则，其实也可以提取出一些逻辑语言描述的命题。比如：

因此，领域知识未必是直白的逻辑语言，但它们总是可以提炼出逻辑命题，这些命题就是我们翻译到类型的指引。

4.1、常见的数据建模

type UserInfo = {
  // 当用户未登录时，id 为空字符串
  id: string;
  // 当用户未登录时，name 为随机生成的昵称
  name: string;
  // 当用户未登录时，email 为空字符串
  email: string;
  // 用户是否登录
  isLogin: boolean;
  // 当邮箱未验证时，这个字段为 false
  isEmailVerified: boolean;
  // 当邮箱已验证时，这个字段为验证时间戳，否则为空字符串
  emailVerifiedAt: string;
};

// Http API 获取用户信息
type JsonResponse = {
  error?: string;
  // 当 error 为空时，这个字段为用户信息
  data?: UserInfo;
};

本案例中的用户信息的数据建模，其实非常简单，大部分开发者都习以为常，很容易写出像上面那种代码，并且不觉得有任何问题。代码简洁、清晰并且直观，注释完整。即便不能说是优质代码，起码是不坏的代码。

4.2、基于 DDD + ADT 的领域类型建模

采用 DDD + ADT 的模型，用户信息的类型大致如下：

type VerifiedEmailInfo = {
  type: 'VerifiedEmailInfo';
  email: string;
  verifiedAt: string;
};

type UnverifiedEmailInfo = {
  type: 'UnverifiedEmailInfo';
  email: string;
};

type EmailInfo = VerifiedEmailInfo | UnverifiedEmailInfo;

type LoginUserInfo = {
  type: 'LoginUserInfo';
  id: string;
  name: string;
  emailInfo: EmailInfo;
};

type GuestUserInfo = {
  type: 'GuestUserInfo';
  name: string;
};

type UserInfo = LoginUserInfo | GuestUserInfo;

type ErrorResponse = {
  type: 'ErrorResponse';
  error: string;
};

type DataResponse = {
  type: 'DataResponse';
  data: UserInfo;
};

type JsonResponse = ErrorResponse | DataResponse;

我们一口气写了 9 个类型，看起来复杂了许多，更多的嵌套，更多的重复字段 (如 email, name 等)，一行注释都没有，代码行数也翻倍了。

然而，上面的代码，更加符合业务规则的描述，更加准确地匹配了领域知识里的 And 和 Or 的关系。如果说它看起来不如第一种简单，那这个复杂度也是领域知识里自身的复杂度，更简单的定义某种意义上是——过度简化。

此外，代码的复杂度，跟代码的长度，不是必然关系。表面上的简单，和实质的简单，也不是一回事儿。

表面上，左侧拥有更少的嵌套，更少的字段，更少的类型，更简短的代码，在形式上无疑是比右侧的更简单的。

实际上，当我们把类型之间的关系标记出来时，我们发现，左侧其实拥有更多的乘法，而右侧则包含几个加法。多个乘法复杂度的类型，允许的 term 的可能性更多，size 更大。因此，左侧的 term size 大于右侧的。

4.3、非法状态对代码库的腐坏

当类型的命题空间，大于领域规则的命题空间，所多出来的部分，就是非法状态的空间。

非法状态将持续腐坏我们的代码库，从以下几个方面可见一斑。

1）非法状态鼓励错误的代码

const handleLoginUser = (userInfo: UserInfo) => {
  // 直接访问 email，而没有先判断是否 isLogin
  console.log('login user email', userInfo.email);
}

对象的字段之间是 product type 的并存关系，即便是未登录的用户，也有 email 字段，只是为空字符串。开发者需要主动的、自觉的记得判断是否登录，否则将产生错误隐患。

2）非法状态导致过度防御性编程，增加代码复杂度和代码量

const handleLoginUser = (userInfo: UserInfo) => {
  // 防御性编程，判断是否已登录
  if (!userInfo.isLogin) {
    return;
  }
  console.log('login user email', userInfo.email);
}

const handleLoginUser1 = (userInfo: UserInfo) => {
  // 防御性编程，判断是否已登录
  if (!userInfo.isLogin) {
    return;
  }
  console.log('login user email', userInfo.email);
}

在所有消费 UserInfo 的函数或者方法中，必须添加防御性逻辑，手动验证和排除非法状态，然后再消费数据。

也就是说，定义类型时所节省的复杂度，在类型消费的所有地方，都额外增加了防御性代码。数据的类型定义只有一处，但数据的消费却可以有很多处。相较之下，整体代码量更多，代码复杂度更高。

3）非法状态带来更多逻辑不同步

很多防御性判断，是在迭代过程中，一点点累积起来的。一开始往往没有收口到通用的函数里，它们重复地出现在多个消费数据的函数里。当需要更新某个防御性判断时，需要开发者记得在所有修改的地方，都改一遍。任何遗漏，都带来防御逻辑的不一致。

正因如此，Don't Repeat Yourself(DRP) 才作为一个最佳实践的指导原则被提出。在这个场景中，DRP 属于治标的做法，治本的做法则是从源头解决，用更精确的类型定义，减少不必要的防御性判断。

4）非法状态带来更差的性能

所有消费数据的函数和方法，都需要带上特定的防御性逻辑。尽管我们可以通过 DRP 原则，将重复的防御性逻辑，收口在一处。但它们仍需在各个消费函数中被调用。

这些消费函数彼此互相调用时，防御性逻辑将被重复执行。即便上一个函数已经调用过，下一个函数依然要进行防御。因为它无法判断是否会被独立的调用，它自身需要做好防御性逻辑的内聚。

因此，非法状态将带来更差的性能，数据验证工作在代码运行期间反反复复地被计算。

4.4、知识和代码同构的巨大收益

与非法状态相反，当代码里的类型更加忠实地反映领域知识，非法状态被减少或消除，它们难以被构造和传播。领域知识被编码到类型里，由 type-checker 进行约束。

从以下几个方面带来巨大收益：

1）拒绝错误的代码

UserInfo 是一个 Sum type，有两种可能性 LoginUserInfo 和 GuestUserInfo。其中 GuestUserInfo 完全符合领域规则描述，只有一个 name 属性，而没有 emailInfo。

因此，user.email 无法通过类型检查。必须先证明 user 属于登录用户，才能访问 emailInfo 属性。

如上，当 user.type === LoginUserInfo 时，我们可以访问 emailInfo。而 user.type === GuestUserInfo 时，emailInfo 是不能访问的。

当我们正确地用 Sum type 表达领域知识里的 Or 的关系，我们更难写出错误的代码。

2）减少不必要的防御性逻辑及其运算开销

我们可以直接使用 Sum type 中，我们感兴趣的部分类型，构造我们的函数。如上所示，处理登录用户时，我们直接用 LoginUserInfo 类型，不必在函数内部防御是否登录。LoginUserInfo 存在，已经意味着已登录。

handleLoginUser1 调用了 handleLoginUser，handleLoginUser2 又调用了 handleLoginUser1。它们都没有额外的防御性逻辑代码。

最外部调用 handleLoginUser2 时，才进行 sum type 分流判断。某种程度上，可以理解为，防御性代码被隔离到最外部的函数调用中。内部函数编写和组合时，代码更短、更安全、更少冗余开销。

3）代码更加容易阅读和维护

相比传统模式，领域知识被放到注释里，描述字段之间的协同关系的业务含义。DDD + ADT 的领域知识，就在类型里。

我们不必去猜测 user.isLogin, user.name, user.emailInfo 彼此之间的依赖关系，猜测有多少种可能的组合和场景。

type EmailInfo = VerifiedEmailInfo | UnverifiedEmailInfo;
type UserInfo = LoginUserInfo | GuestUserInfo;
type JsonResponse = ErrorResponse | DataResponse;

我们可以很直观地看到，两种就是两种，没有注释也能正确理解。不仅开发者理解，编译器也理解，并在每次消费 Sum type 时，约束开发者使其难以忘记和误解。

4.5、小结

不健康的代码状态空间，非法状态和副作用随机分布。需要靠开发者付出更多额外的努力、写更多的注释、更多的防御性代码……，才能缓解代码腐坏的进程。然而，没有从源头解决问题，治标不治本，最终非法状态的蔓延，将很容易超出开发团队的掌控能力。特别是在人员流失和更替的过程中，领域知识在上一任开发者的脑海里，随着上一任的离去而丢失，在下一任开发者在脑海里重新建立领域知识的过程中，代码库可能已经加速腐坏。

通过 DDD + ADT，我们可以构建更健康的代码状态空间，用更精确和反映领域知识的类型，将非法状态的防御性判断逐层隔离到边界。让我们的核心代码变得简单可靠，领域知识被编码到类型里，由编译器的 type-checker 进行保证。即便开发者产生更替，编译器依然可以做出正确的提示。

通过 ADT 让非法状态无法被表示出来，从根源上优化代码质量。

5、案例：用 DDD + ADT 做流程建模

假设有以下领域规则：

5.1、常见的流程建模

class Post {
  constructor(
    private isDraft: boolean,
    private isReviewing: boolean,
    private isPublished: boolean,
    private content: string
) {}
  edit(content: string) {
    if (!this.isDraft) {
      throw new Error('Post is not in draft stage');
    }
    this.content = content;
  }
  review() {
    if (!this.isDraft) {
      throw new Error('Post is not in draft stage');
    }
    this.isDraft = false;
    this.isReviewing = true;
  }
  publish() {
    if (!this.isReviewing) {
      throw new Error('Post is not in reviewing stage');
    }
    this.isReviewing = false;
    this.isPublished = true;
  }
  reject() {
    if (!this.isReviewing) {
      throw new Error('Post is not in reviewing stage');
    }
    this.isReviewing = false;
    this.isDraft = true;
  }
}

很多开发者很自然地编写出了上述代码逻辑。当调用 edit 方法编辑内容时，会先判断是否处于草稿阶段。每个相关方法内，都有状态验证。

问题在于，这种做法跟业务规则不是同构的。在业务规则中，编辑、审核、发布、退回等操作，不完全是并存的，而是随着草稿阶段、审核阶段、发布阶段而变化。但在 Post Class 中，edit, review, publish 和 reject 等方法并存，是 product type 的关系，没有忠实地体现领域知识。

因此，Post 的实例，存在很多非法操作 (Illegal Operations)。每一次方法调用，都需要调用者提前判断当前阶段，否则调用 edit 等方法将抛出错误。有意无意地忘记提前防御判断，Bug 将蔓延在代码库里。

当我们把各个方法里的防御性逻辑，从 throw error 改成静默，即只在符合条件时执行操作，否则什么都不做。那么，非法操作 (Illegal Operations) 将变成不预期行为(Unexpected Behaviors)。也就是说，所有方法调用，我们都不确定是否产生了效用，常常仍需额外的判断逻辑去确认。

非法操作一旦存在，不管以何种方式隐瞒不报，都会持续腐坏代码库。

5.2、基于 DDD + Class 的忠实流程建模

export class DraftPost {
  constructor(private content: string) {}
  edit(content: string) {
    this.content = content;
  }
  review() {
    return new ReviewingPost(this.content);
  }
}

class ReviewingPost {
  constructor(private content: string) {}
  publish() {
    return new PublishedPost(this.content);
  }
  reject() {
    return new DraftPost(this.content);
  }
  approve() {
    return new PublishedPost(this.content);
  }
}

class PublishedPost {
  constructor(private content: string) {}
  getContent() {
    return this.content;
  }
}

如上所示，我们定义了三个 Class，分别表达三个阶段的 Post，对于每个阶段，所允许的方法都精确对应了领域规则。只有 DraftPost 拥有 edit 方法，是可编辑的；只有 ReviewingPost 拥有 publish 方法，是可发布的。

当我们获取到 DraftPost 实例，我们可以编辑它，但不能跳过审核直接 publish 发布它。

当我们获取到 ReviewingPost 的实例，我们可以发布它，但不能编辑它。

当我们获取到 PublishPost 的实例，我们既不能编辑，也不能重复发布它。

业务规则描述的流程，被编码到各个阶段的 Post 的方法调用的传递中，由编译器的 type-checker 去约束。

5.3、基于 DDD + ADT 的忠实流程建模

type DraftPost = {
  type: 'DraftPost';
  content: string;
}

type ReviewingPost = {
  type: 'ReviewingPost';
  content: string;
}

type PublishedPost = {
  type: 'PublishedPost';
  content: string;
}

const edit = (post: DraftPost, newContent: string): DraftPost => {
  return {
    ...post,
    content: newContent
  }
}

const review = (post: DraftPost): ReviewingPost => {
  return {
    type: 'ReviewingPost',
    content: post.content
  }
}

const approve = (post: ReviewingPost): PublishedPost => {
  return {
    type: 'PublishedPost',
    content: post.content
  }
}

const reject = (post: ReviewingPost): DraftPost => {
  return {
    type: 'DraftPost',
    content: post.content
  }
}

除了用 Class 进行流程建模以外，面向数据的 ADT 也能做到，两者在流程建模的表达上是等价的。区别在于，数据和行为不再被放到一起，而是分开定义。但我们的 edit 只接受 DraftPost 数据，因而表达了只有草稿阶段才能编辑。review, approve, reject 等函数同理。

5.4、小结

采用 DDD + ADT 的模型，让非法操作不能被调用，从根源上优化代码质量。

6、总结

不管是用户信息的数据建模，还是 Post 的流程建模，都是很常见的业务需求。它们的逻辑并不复杂，甚至在本文中还做了简化。即便如此，我们可以看到，大部分开发者下意识的代码实现，都包含着诸多隐患。存在很多难以消除的非法状态，以及难以管理的非法操作，不断地侵蚀着代码库。

可以想象，随着项目迭代，持续泄漏的非法状态和非法操作，将指数级地增加项目复杂度，让代码库难以理解、难以阅读和难以维护。犯错是被鼓励的，领域知识被写在不可运行和检查的注释中，代码的性能、逻辑一致性等诸多指标得不到保障。

而 DDD + ADT 模式，可以从根源上改变现状，优化代码库的整体质量。

不仅从产品功能和行为的外延意义上，满足了业务需求；从代码的逻辑细节等内涵意义上，也满足了业务知识的要求。

让我们再回顾一下，我们想要的代码质量提升模型：

ADT+DDD 模式，更好地达到了上述目标。它们不仅仅是在代码工程领域的经验总结，背后其实有着一个世纪的学术积累与沉淀。

用 Phillip Wadle 的话来说，ADT 不是发明的，而是发现的。大部分开发者使用的编程语言及其特性，主要都是人类的发明。现在邀请大家来用人类所发现的语言特性。

每一行 DDD + ADT 的建模代码，背后都承载着历史的厚重、闪耀着人类理性的光辉。
https://zhuanlan.zhihu.com/p/475789952?utm_source=wechat_session&utm_medium=social&utm_oi=29435885518848&utm_campaign=shareopn