14. 精读《架构设计之 DCI》

本期精读文章是《the dci architecture》，让我们一起来探索和复习这种设计思想。

1. 引言

随着前端技术如ES6和ES7的发展，我们大前端借鉴了各种其他编程语言中的概念、特性和模式。我们可以使用函数式编程、面向对象编程、面向接口的思想、AOP、注解、代理、反射以及各种设计模式。在大前端和数据时代的发展背景下，我们重新阅读了这篇关于设计的老文《The DCI Architecture》，以探索和复习相关的设计和思想。

2. 内容摘要

DCI是数据（Data）、场景（Context）和交互（Interactions）的简称，重点关注数据在不同场景中的交互行为，是面向对象系统状态和行为的一种范式设计。DCI在许多方面统一了过去的多种范式，这些模式多年来已成为面向对象编程的辅助工具。

尽管面向切面编程（AOP）也有其他用途，但DCI满足了许多AOP的应用以及Aspects在解决问题方面的许多目标。根据AOP的基本原理，DCI基于深层次的反射或元编程。与Aspects不同，角色聚合并组合得很好。Context提供角色集之间的关联范围关闭，而Aspect仅与应用它们的对象配对。虽然混合本身缺乏我们在Context语义中发现的动力，但DCI反映了混合风格策略。DCI实现了多范式设计的许多简单目标，能够将过程逻辑与对象逻辑分开。然而，DCI具有比多范式设计提供的更强大的技术更好的耦合和内聚效果。

结合ATM汇款场景案例，讲解了DCI角色提供了与用户相关的自然边界。以转账为例，我们实际谈论的是钱的转移，以及源账户和目标账户的角色，算法（用例角色行为集合）应该是这样：

1. 账户拥有人选择从一个账户到另一个账户的钞票转移。
2. 系统显示有效账户。
3. 用户选择源账户。
4. 系统显示存在的有效账户。
5. 账户拥有人选择目标账户。
6. 系统需要数额。
7. 账户拥有人输入数额。
8. 钞票转移账户进行中（确认金额、修改账户等操作）。

设计者的工作就是把这个用例转化为类似交易的算法，如下：

1. 源账户开始交易事务。
2. 源账户确认余额可用。
3. 源账户减少其账目。
4. 源账户请求目标账户增加其账目。
5. 源账户请求目标账户更新其日志。
6. 源账户结束交易事务。
7. 源账户显示给账户拥有人转账成功。

代码语言：javascript 代码运行次数：0

template 
class TransferMoneySourceAccount: public MoneySource {
private:
    ConcreteDerived *const self() {
        return static_cast(this);
    }
    void transferTo(Currency amount) {
        // This code is reviewable and
        // meaningfully testable with stubs!
        beginTransaction();
        if (self()->availableBalance() >= amount) {
            self()->decreaseBalance(amount);
            recipient()->increaseBalance(amount);
            self()->updateLog("Transfer Out", DateTime(), amount);
            recipient()->updateLog("Transfer In", DateTime(), amount);
        }
        gui->displayScreen(SUCCESS_DEPOSIT_SCREEN);
        endTransaction();
    }
};

3. 精读

本次提出独到观点的同学有：@ascoders、@TingGe、@zy，精读由此归纳。

尝试从人类思维角度出发理解DCI，即数据（data）、场景（context）和交互（interactive）。

DCI之所以被提出，是因为传统MVC代码在越来越丰富的交互需求中变得越来越难读。有人会觉得，复杂的需求MVC也可以cover住，诚然如此，但很少有人能只读一遍源码就能理解程序处理了哪些事情，这是因为人类思维与MVC的传统程序设计思想存在鸿沟，我们需要脑补内容很多，才会觉得难度。

现在仍有大量程序使用面向对象的思想表达交互行为，当我们把所有对象之间的关联记录在脑海中时，可能对象之间交互行为会比较清楚，但仍然无法轻松理解，因为对象的封装会导致内聚性不断增加，交互逻辑会在不同对象之间跳转，对象之间的嵌套关系在复杂系统中无疑是一个理解负担。

DCI尝试从人类思维角度出发，举一个例子：为什么在看电影时会轻轻松松地理解故事主线呢？回想一下我们看电影的过程，看到一个画面时，我们会思考三件事：

赶鸟企业网站管理系统2.0

赶鸟企业网站管理系统 2.0，是在已往系统的基础上经过重新设计和架构形成的。系统以任务为主导和以通用企业网站管理为目标而构建，前台页面精美漂亮、速度超快，后台功能强大、简单易用。整套系统完整无错，是企业建站之必备良品。功能介绍：基本设置：网站信息、联系方式、联系我们等；产品管理：分类管理、产品管理；新闻管理：分类管理、新闻管理；人才招聘：发布人才招聘信息，访客直接应聘职位；留言反馈：客户留言信息反

下载

• 画面里有什么人或物？
• 人或物发生了什么行为、交互？
• 现在在哪？厨房？太空舱？或者原始森林？

很快把这三件事弄清楚，我们就能快速理解当前场景的逻辑，并且轻松理解该场景继续发生的状况。即便是盗梦空间这种烧脑的电影，当我们搞清楚这三个问题后，就算街道发生了180度扭曲，也不会存在理解障碍，反而可以吃着爆米花享受，直到切换到下一个场景为止。

当我们把街道扭曲180度的能力放在街道对象上时，理解就变得复杂了：这个函数什么时候被调用？为什么不好好承载车辆而自己发生扭曲？这就像电影开始时，把电影里播放的所有关于街道的状态都走马灯过一遍：我们看到街道通过了车辆、又卷曲、又发生了爆炸，实在觉得莫名其妙。

理解代码也是如此，当交互行为复杂时，把交互和场景分别抽象出来，以场景为切入点交互数据。

举个例子，传统的MVC可能会这么组织代码：

UserModel:

代码语言：javascript 代码运行次数：0

class My {
    private name = "ascoders"; // 名字
    private skills = ["javascript", "nodejs", "切图"]; // 技能
    private hp = 100; // 生命值？？
    private account = new Account(); // 账户相关
}

UserController:

代码语言：javascript 代码运行次数：0

class Controller {
    private my = new My();
    private account = new Account();
    private accountController = new AccountController();
    public cook() {
        // 做饭
    }
    public coding() {
        // 写代码
    }
    public fireball() {
        // 搓火球术。。？
    }
    public underAttack() {
        // 受到攻击？？
    }
    public pay() {
        // 支付，用到了 account 与 accountController
    }
}

这只是我自己的行为，当我这个对象，与文章对象、付款行为发生联动时，就发生了各种各样的跳转。到目前为止我还不是非常排斥这种做法，毕竟这样是非常主流的，前端数据管理中，不论是redux，还是mobx，都类似MVC。

不论如何，尝试一下DCI的思路吧，看看是否会像看电影一样轻松地理解代码：