面向对象不是银弹，DDD 也不是，TypeScript 才是

要解决的问题是什么？

A problem well-stated is Half-solved

Fred Brooks 在著名的"No Silver Bullet - Essence and Accident in Software Engineering"中提出了这么几点复杂度

• Complexity
• Conformity
• Changeability
• Invisibility

在另外一篇著名的"Out of the Tar Pit"中，提出了更具体的这么三种复杂度复杂度的原因

• Complexity caused by State
• Complexity caused by Control
• Complexity caused by Volume

两者共同点就是都是把 State 放在了 complexity 的原因里。

Imperative Programming 的问题是什么？

我们并不是没有办法去更新这些 State，Imperative Programming 的方式非常直观，就是把一堆读写状态的指令给CPU，CPU就会去一五一十地执行。我们可以把软件地执行过程画成这样地一棵树：

软件的外在行为，就是按照时间顺序，产生一系列的状态更新。也就是这些黄色的节点，以及这些节点的时间顺序。但是问题是：

这种一五一十地，按时间顺序描述这些黄色节点的编程风格，产生出来的源代码并不是 simple 的，也不是 readable 的。

即使我们抽了很多很好的函数，也就是这些蓝色的圈圈。仍然不会产生本质的变化。我去年写了两篇关于代码可读性的文章：zhuanlan.zhihu.com/p/46435063 和 zhuanlan.zhihu.com/p/34982747 。现在看来有点太啰嗦了。而且 readable 是一个偏主观的概念。Rich Hickey 有一个演讲 "Simple Made Easy" 讲得很好，他说 simple 是一个客观的指标。我把 Simple 具体为以下四个可以客观度量的属性

• Quantity small：数量上少
• Sequential：串行的
• Continuous：上一行和下一行有必然的因果关系的必要。而有因果关系的逻辑，不应该相距太远
• Isolated：事情之间的相互影响小。能够 isolate，才意味着可以变成组件分解出来

与这四个属性相反的是

• Quantity large：数量上多
• Concurrent, parallel：并发是逻辑上的，并行是物理上的。无论是哪种，都比 sequential 更复杂。
• Long range causality：长距离的因果关系
• Entangled：剪不断理还乱

Imperative Programming 代表的是这个真实世界。真实世界就是 Quantity large，无时无刻不 parallel，到处都是 long range causality，而且 entangled 的。Simplicity 是代表了人们假想的伊甸园，是我们对肉脑薄弱的感知和计算能力的迁就。Simplicity is hard，when simplicity is not the reality。

所以，我们可以把要解决的问题，分解成这两个问题：

1. 给我们的肉脑创造一个虚拟的伊甸园，在这里， Quantity small，Sequential，Continuous，Isolated。
2. 因为伊甸园脱离了真实世界。所以当在残忍的真实世界里出了问题，能够提供工具帮助人类理解实际发生的 Quantity large, concurrent / parallel，long range causality，entangled。

OOP/DDD 解决了上面的四个问题么？

DDD 可以认为是这么三步

1. Application Service 加载 Domain Model
2. 由 Aggregate Root 封装对状态的修改
3. 副作用体现为 Domain Model 的更新，以及产生的 Domain Event

其核心就是可以聚合根对状态的黑盒封装。这种所谓的黑盒封装有两个问题

1. 说到底，聚合根的method，和 imperative programming 的 function，没有本质区别
2. 对象之间的交互，特别是业务流程对多个对象的更新，没有自然的聚合根的归属。或者说，真正的聚合根应该是业务流程本身。但是流程并不是 Entity。

为什么说没有本质区别：

• Quantity small：在 OOP/DDD 里所有的状态仍然是按时间顺序去逐个更新的，一个没少
• Sequential：为了性能，仍然是要把代码写成多协程或者多线程的模式
• Continuous：一个完整的业务流程，还是被拆成了各个API 的 controller里。然而经常在一个 controller 里，处理着只是恰好同时发生，但是业务逻辑上没有彼此关联的代码。
• Isolated：ORM给我们创造出了一个幻觉，然后1+N查询的问题把我们拉回了现实。这种要求Application Service一次性把整个Domain Model加载到内存的做法，就一点都不isolated。经常有一种，倒不如把代码都写在Application Service拉倒的感觉。

综上面向对象不是那颗银弹，DDD也不是。

TypeScript 是如何解决这四个问题的？

TypeScript 解决了以上四个问题

View 绑定到数据

首先要解决的问题是尽可能减少 State。比如说我们可以让 View 是“无状态”的，把所有的 View 绑定到数据上。例如为了实现这样的功能：

对应的 View 是 Html 的 DOM，这本身是一份状态。但是我们可以把它绑定到数据上：

<Button @onClick="onMinusClick">-</Button>
<span margin="8px">{{ value }}</span>
<Button @onClick="onPlusClick">+</Button>

对应的数据

export class CounterDemo extends RootSectionModel {
    value = 0;
    onMinusClick() {
        this.value -= 1;
    }
    onPlusClick() {
        this.value += 1;
    }
}

为什么这样算消除状态？在this.value被写入的时候，DOM这份状态不是还是被更新了吗？为什么认为this.value -= 1不算状态，this.value -= 1 然后接着 this.updateView(this.value) 就算状态呢？核心问题在于绑定的实质在于，它描述两个状态之间的恒等关系。这个关系不是在时间轴内的。这样当我们对时间进行叙事的时候，就可以忽略掉被绑定了的状态了。这个就是绑定可以减少状态的核心原理。

前端状态绑定到数据库状态

我们可以来看一下，整个系统里都有哪些状态。

仅仅托管了界面状态是不够的。只是把问题转移了，不是还要管理前端状态么？各种redux？所以还要进一步化简，对每一份状态，都要回答，有没有简化的可能？

比如我们希望直接把前端状态和数据库里主存储的状态来个绑定。

这是一个很常见的列表展示页的需求。我们当然可以封装一个后端的domain object，然后再搞几个url，封装一下dto，然后再前端封装几个view model，然后再展示出来。我们也可以这样：

<CreateReservation />
<Card title="预定列表" margin="16px">
    <Form layout="inline">
        <InputNumber :value="&from" label="座位数 from" />
        <span margin="8px"> ~ </span>
        <InputNumber :value="&to" label="to" />
    </Form>
    <span>总数 {{ totalCount }}</span>
    <List :dataSource="filteredReservations" itemLayout="vertical" size="small">
        <json #pagination>
            { "pageSize": 10 }
        </json>
        <slot #element="::element">
            <ShowReservation :reservation="element.item">
        </slot>
    </List>
    <Row justifyContent="flex-end" marginTop="8px">
        <Button type="primary" icon="plus" @onClick="onNewReservationClick">预定</Button>
    </Row>
</Card>

然后对应绑定到的对象是这样写的：

export class ListDemo extends RootSectionModel {
    public from: number = 1;
    public to: number = 9;
    public get filteredReservations() {
        return this.scene.query(Reservation_SeatInRange, { from: this.from, to: this.to });
    }
    public get totalCount() {
        return this.filteredReservations.length;
    }
    public onNewReservationClick() {
        this.getSectionModel(CreateReservation).isOpen = true;
    }
    public viewCreateReservation() {
        return this.scene.add(CreateReservation);
    }
}

我们可以看到， from 的值变了之后，filteredReservations 变了，totalCount 也跟着变了。如果数据源是一个数组，这个 demo 其实没啥。但是注意这里的数据源是 Mysql 数据库。但是我们使用的时候就像操作本地数组一样方便。

这里我们通过类似 GraphQL 的通用后端接口，把前端后端，中间RPC的状态都给合并成一个了。但是和 GraphQL 前端定义查询的做法不同，所能够查询的东西仍然是提前注册的，这样可以避免前端滥用无索引的查询的问题。这里做这个注册工作的就是 Reservation_SeatInRange，其定义是这样的

@sources.Mysql()
export class Reservation extends Entity {
    public seatCount: number;
    public phoneNumber: string;
}

@where('seatCount >= :from AND seatCount <= :to')
export class Reservation_SeatInRange {
    public static SubsetOf = Reservation;
    public from: number;
    public to: number;
}

省掉前后端互相翻译添加的额外状态

前端和后端都是在处理同一个流程的同一个步骤，其上下文是高度一致的。我们可以认为实际上有两层 RPC

当这个 RPC 协议完全服务于对应的页面表单的前提下，这个RPC协议的 request 和 response 状态基本上等价于页面表单的状态。当然你可以说，RPC协议可以是通用的，是可以复用的，和前端无关的。正是因为有这样的态度，所以才会多出来 BFF 这么额外的一层，不是么。创造新的问题。

假设要实现上面这个简单的表单。其视图是这样的

<Card title="餐厅座位预定" width="320px">
    <Form>
        {{ message }}
        <Input :value="&phoneNumber" label="手机号" />
        <InputNumber :value="&seatCount" label="座位数" />
        <Button @onClick="onReserveClick">预定</Button>
    </Form>
</Card>

然后我们把这个视图绑定到一个表单对象上，它同时兼任了前后端RPC交互协议的职责：

@sources.Scene
export class FormDemo extends RootSectionModel {
    @constraint.min(1)
    public seatCount: number;
    @constraint.required
    public phoneNumber: string;
    public message: string = '';

    public onBegin() {
        this.reset();
    }

    public onReserveClick() {
        if (constraint.validate(this)) {
            return;
        }
        this.saveReservation();
        setTimeout(this.clearMessage.bind(this), 1000);
    }

    @command({ runAt: 'server' })
    private saveReservation() {
        if (constraint.validate(this)) {
            return;
        }
        const reservation = this.scene.add(Reservation, this);
        try {
            this.scene.commit();
        } catch (e) {
            const existingReservations = this.scene.query(Reservation, { phoneNumber: this.phoneNumber });
            if (existingReservations.length > 0) {
                this.scene.unload(reservation);
                constraint.reportViolation(this, 'phoneNumber', {
                    message: '同一个手机号只能有一个预定',
                });
                return;
            }
            throw e;
        }
        this.reset();
        this.message = '预定成功';
    }

    private reset() {
        this.seatCount = 1;
        this.phoneNumber = '';
    }

    private clearMessage() {
        this.message = '';
    }
}

实际存储在数据库里，不是这个表单，是另外一个：

@sources.Mysql()
export class Reservation extends Entity {
    public seatCount: number;
    public phoneNumber: string;
}

我们通过以下手段，把状态要么省掉，要么从一个需要手工管理的状态变成一个衍生状态：

• 转化为衍生的状态：计算属性，状态同步，视图表，物化视图表，缓存
• 让远端的状态就像在本地一样直接使用
• 减少因为网络传输引入的临时状态

Sequential 表达，Concurrent 执行

在兑现了一个 Quantity small 的目标之后，我们来看第二个目标，让代码 sequential。代码 sequential 其实很简单，就是串行写就好了。难题是，如果执行的时候也是 sequential，就会导致加载速度很慢。我们有两个可以参考学习的对象：

• CPU 的投机执行：虽然我们给 CPU 单核的是串行的指令流，但是CPU可以在没有数据依赖的情况下尽量投机并发执行。
• Facebook Haxl：wiki.haskell.org/wikiupload/…

假设有这样两张表：

CREATE TABLE `User` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL,
  `inviterId` int(11) NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1;

CREATE TABLE `Post` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` varchar(255) NOT NULL,
  `authorId` int(11) NOT NULL,
  `editorId` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1;

对应的类定义：

@sources.Mysql()
export class User extends Entity {
    public id: number;
    public name: string;
    public inviterId: number;
    public get inviter(): User {
        return this.scene.load(User, { id: this.inviterId });
    }
    public get posts() {
        return this.scene.query(Post, { authorId: this.id });
    }
}
@sources.Mysql()
export class Post extends Entity {
    public id: number;
    public title: string;
    public authorId: number;
    public get author(): User {
        return this.scene.load(User, { id: this.authorId });
    }
    public get editor(): User {
        return this.scene.load(User, { id: this.editorId });
    }
    public get authorName(): string {
        return this.author.name;
    }
    public get inviterName(): string {
        const inviter = this.author.inviter;
        return inviter ? inviter.name : 'N/A';
    }
}

那么去访问 author 和 editor 的时候，可以写成串行的：

const author = somePost.author
const editor = somePost.editor
return { author, editor }

但是因为中间没有实际访问过这两个对象，所以没有实际的数据依赖，这样的串行代码就会被并发执行。但是这样的访问

const author = somePost.author
const authorInviter = author.inviter
return { author, authorInviter }

因为 author.inviter 产生了数据依赖，这样就没法并发执行。所以这样就提供了一个用串行代码，利用数据的依赖关系来表达并发的方式。

Isolated，让组件只用管自己

然后我们来看第三个目标，Isolated。

假设要把 Post 渲染成上面这样的表格。我们知道“作者”和“邀请人”这两个字段都是外键关联的。所以如果没有任何优化，就是 Isolated 写，Isolated 执行，那么必然是会产生额外的 N + N 条子查询，这里 N 就是 4 行。

但是实际执行的时候只产生了 3 条查询，第一条是查询有多个 Post，第二条查询所有的作者，第三条查询所有的这些作者的邀请人。这里把多个 HTTP 请求合并成三条的 IO 合并是自动做的。

2019-07-19T11:25:04.136927Z	   27 Query	START TRANSACTION
2019-07-19T11:25:04.137426Z	   27 Query	SELECT id, title, authorId FROM Post
2019-07-19T11:25:04.138444Z	   27 Query	COMMIT
2019-07-19T11:25:04.772221Z	   27 Query	START TRANSACTION
2019-07-19T11:25:04.773019Z	   27 Query	SELECT id, name, inviterId FROM User WHERE id IN (10, 9, 11)
2019-07-19T11:25:04.774173Z	   27 Query	COMMIT
2019-07-19T11:25:04.928393Z	   27 Query	START TRANSACTION
2019-07-19T11:25:04.936851Z	   27 Query	SELECT id, name, inviterId FROM User WHERE id IN (8, 7, 9)
2019-07-19T11:25:04.937918Z	   27 Query	COMMIT

查询 mysql 的 general log，可以看到原来的 id = xxx 的查询编程了 id IN (xxx) 的查询了。所以不仅仅是合并成了两次 HTTP 请求，而且进一步合并成了两次 Mysql 查询。

这样就可以避免要求 Application Service 一次性拿一个大的 JOIN 查询把所有的领域层需要的数据全部加载进来这样的要求。可以让代码该 Isolated 的，就保持 Isolated 的。每个组件管好自己的事情，绑好自己的数据，不用管其他人都在干什么。

Continous 的业务流程

我们来看最后一个属性，Continuous。前面提到了两个问题

• 在DDD里，业务流程不知道归属给什么聚合根。
• Imperative Programming 会把连续的业务流程，切碎成小段来执行。前后逻辑通过全局状态（也就是数据库）来传递因果性。

我们的解决方案就是提供一种 Entity 叫 Process。它和其他的 Entity 一样，绑定了数据库表，就是数据的载体。同时它又代表了业务流程。也就是我们把一个业务流程函数，持久化成 Entity 了。也可以说我们把业务单据变成可执行的函数了。

假设需要实现上面所示的 Account 的生命周期。一开始账户是处于锁定状态，除非设置了密码。然后登录允许失败，但是最多失败三次。如果超过三次，则回到锁定状态。这个业务逻辑，用 Process 来写是这样的：

const MAX_RETRY_COUNT = 3;

@sources.Mysql()
export class Account extends Process {
    public name: string;
    // plain text, just a demo
    public password: string;

    public retryCount: number;

    public reset: ProcessEndpoint<string, boolean>;

    public login: ProcessEndpoint<string, boolean>;

    public process() {
        let password: string;
        while (true) {
            locked: this.commit();
            const resetCall = this.recv('reset');
            password = resetCall.request;
            if (this.isPasswordComplex(password)) {
                this.respond(resetCall, true);
                break;
            }
            this.respond(resetCall, false);
        }
        let retryCount = MAX_RETRY_COUNT;
        for (; retryCount > 0; retryCount -= 1) {
            normal: this.commit();
            const loginAttempt = this.recv('login');
            const success = loginAttempt.request === password;
            this.respond(loginAttempt, success);
            if (success) {
                retryCount = MAX_RETRY_COUNT + 1;
                continue;
            }
        }
        __GOBACK__('locked');
    }

    private isPasswordComplex(password: string) {
        return password && password.length > 6;
    }
}

这个实体是持久化的，表结构是这样的：

CREATE TABLE `Account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) NOT NULL UNIQUE,
  `password` varchar(255) NOT NULL,
  `status` varchar(255) NOT NULL,
  `retryCount` int(11) NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=latin1;

所以并不是什么把 javascript 协程持久化成不可读的二进制那样的技术，那个是上一代的持久化协程了。值得注意是有一个 status 字段，这个和代码中的 label statement 是对应的执行到了对应的行，status 就会被设置成对应的值。相比使用独立的 BPM 引擎，我们无须额外管理流程上下文，以及同步流程状态回业务的数据库。流程就是业务单据业务实体，业务单据就承载了流程。

这样我们就同时解决了 DDD 里流程逻辑不知道往哪里放的问题，就应该放到流程单据上。例如订单，报价单，这些代表了流程状态的单据表。同时我们也解决了 continous 的问题。但是这样的一个大 process() 函数怎么用呢？不能每次都从头执行吧。使用的代码长这个样子:

这是展示界面 AccountDemo.xml

<Form width="320px" margin="24px">
    <Input label="用户名" :value="&name" />
    <Input label="密码" :value="&password" />
    <switch :value="status">
        <slot #default><Button @onClick="onLoginClick">登录</Button></slot>
        <slot #locked><Button @onClick="onResetClick">重新设置密码</Button></slot>
    </switch>
    {{ notice }}
</Form>

界面是 reactive 的，流程驱动到了什么状态，就对应展示什么状态的交互。

这是界面对应的 AccountDemo.ts

@sources.Scene
export class AccountDemo extends RootSectionModel {
    @constraint.required
    public name: string;

    @constraint.required
    public password: string;

    private justFailed: boolean;

    private get account() {
        const accounts = this.scene.query(Account, { name: this.name });
        return accounts.length === 0 ? undefined : accounts[0];
    }

    public get notice() {
        if (this.justFailed === undefined) {
            return '';
        }
        if (this.justFailed === false) {
            return '登录成功';
        }
        if (!this.account) {
            return '';
        }
        if (this.account.status === 'locked') {
            return '账户已被锁定';
        }
        return `还剩 ${this.account.retryCount} 次重试`;
    }

    public get status() {
        if (!this.justFailed || !this.account) {
            return 'default';
        }
        return this.account.status;
    }

    public onLoginClick() {
        if (constraint.validate(this)) {
            return;
        }
        if (!this.account) {
            constraint.reportViolation(this, 'password', {
                message: '用户名或者密码错误',
            });
            return;
        }
        try {
            const success = this.scene.call(this.account.login, this.password);
            if (!success) {
                throw new Error('failed');
            }
            this.justFailed = false;
        } catch (e) {
            this.justFailed = true;
            constraint.reportViolation(this, 'password', {
                message: '用户名或者密码错误',
            });
            return;
        }
    }

    public onResetClick() {
        if (this.account) {
            this.scene.call(this.account.reset, 'p@55word');
        }
    }
}

通过 Process 暴露出来的 ProcessEndpoint，我们可以驱动这个流程。如果不需要返回值，用 ProcessEvent 单向通信也可以。

通过 Process，我们可以把一个流程的状态修改都封装到这个 Process 里，实现真正的封装。同时对于，流程内的分叉合并这些可以表达起来更自然。以及一个用户操作，需要同时驱动多个Process的情况，比如同时要处理营销流程，售卖流程，仓储库存流程之类的，可以很好的实现各自的独立闭环。而不用在一个大的 controller 里，把所有人的业务都做一点点。

所以，OOP/DDD 不够看的，得上 TypeScript。但是，你这里的 TypeScript 是 TypeScript 吗？

你们是谁？

我们的名字叫乘法云。我们在挑战的问题是

从业务想法到软件上线，速度如何提高10x？

这里演示的 TypeScript 语法，可以完全通过 eslint/tslint 的检查，是纯正的 TypeScript。但是我们有自己的 aPaaS 平台，实现了以上所有的功能的运行时支持。官网和 IDE 正在紧张招人开发中。以下是广告时间，谢谢阅读。

求前端！求前端！求前端！

我们为顶尖工程师提供了与之相配的技术发挥空间、无后顾之忧的宽松工作环境以及有竞争力的薪酬福利。同时也为高潜质的行业新人提供充分的学习和成长机会。

这里，没有996，崇尚高效。
这里，话语权不靠职级和任命，靠的是代码的说服力。
这里，不打鸡血，我们用理性和内驱力去征服各种挑战。
这里，也会有项目排期，但不怕delay，我们有充足的时间，做到让自己更满意。

工作地点在北京西二旗，薪酬待遇见招聘链接：www.zhipin.com/job_detail/…