设计匠艺 | 清晰的设计意图

如果你不能清晰地表达设计意图，追求简单无疑就是一个笑话。语言的纠缠不清，实则暴露了你思想的混乱，就像行走在陌生城市的异乡人，城市地图成了他唯一的指路明灯。糟糕的是，地图用唯一的色彩试图简单阐明简单的本质，却因为缺乏清晰的层次感让人变得无所适从。当然，还有一个重要的原因，城市本身是一种混乱的复杂。

不能简单地阐述设计意图，就有他人无法理解系统的危险。架构最好是不言自明的，至少，也是能够用语言表达清楚的。正如爱因斯坦所说：“如果你不能向一个六岁小孩解释某件事，那么你自己就没有真正理解它。”架构是团队知识传递（分享）的重要部分。聪明的做法是在架构过程中选择遵守一种设计原则，并运用一种或多种一致的模式或风格。

Ruby On Rails之所以能够得到普遍流行，正是基于这一原因。它的整个设计意图可以由“惯例优于配置”原则和MVC模式来阐释。

Rails的目的很单一，就是基于MVC模式打造一个敏捷的Web框架。Model、View与Controller之间的关系其实暗含了一种契约，并且这种契约关系是相对不变的。不变的内容总是可以通过某种方式在架构中固定下来。传统的设计方式是运用接口来稳定架构，前提是我们需要寻找到不变的契约是可以抽象的，然后再将扩展交给实现类。

Java多线程编程中的Runnable接口的设计体现了这一点。而在函数式编程语言中，这种不变性则透过基本的函数来体现，再以组合子的方式满足变化的需求。

Rails是另一种钳制变化的方式，它将契约视为一种惯例，以运行时的动态组装取代静态的配置。表面上施加了约束，限制了灵活，事实上这种牺牲换来的是无与伦比的简单之美。

UNIX的设计意图是一种哲学，即“Keep It Simple Stupid”，正是遵循了这一设计意图，UNIX才取得了成功。

你的设计意图清晰吗？

虽然Spring是Rod Johnson在几个商业项目中运用J2EE时，逐步演化出来的框架，但它的设计意图在整个演化过程中却始终如一地坚持：摒弃EJB的笨拙，转而以轻量级的框架与容器。

Datomic数据库的架构意图极为清晰，就是要创建一个不可变的数据库。“Datomic将数据库视为信息系统，而信息是一组事实（facts），事实是指一些已经发生的事情。鉴于任何人都无法改变过去，这也意味着数据库将累积这些事实，而非原地进行更新。虽然过去可以遗忘，但却是不能改变的。因此，如果某些人“修改了”他们的地址，Datomic会存储他们拥有新地址这个事实，而非替换掉老的事实（它只是在这个时间点被简单的回收了）。这个不变性（immutability）带来了很多重要的架构优势和机会。”

意图是一种导向，在架构层面，意图体现为根据架构目标遵循设计原则做出的架构决策。