来自架构的尖叫|附：简洁架构原则经典演讲

球迷Long导语

若我们正在查看这建筑的设计架构图，那么架构图到底应包括什么呢？

翻译：孙宇聪

编译：球迷Long

它们在喊什么

如果这是一幅单户住宅的建筑架构图，那么我们很可能会先看到一个大门，然后是一条连接到起居室的通道，同时可能还会看到一个餐厅。接着，距离餐厅不远处应该会有一个厨房，可能厨房附近还会有一个非正式用餐区，或一个亲子房。

当我们阅读这个架构图时，应该不会怀疑这是一个单户住宅。几乎整个建筑设计都在尖叫着告诉你：这是一个“家”！

假设我们阅读的是一幅图书馆的建筑设计图，情况也差不多。我们应该会先看到一个超大入口，然后是一个用于签到/签出的办公区，接下来是阅读区、小型会议室，以及一排排的书架区。同样，几乎整个建筑设计都在尖叫着跟你说：这是一个“图书馆”。

那么，我们的应用程序的架构设计又会“喊”些什么呢？当我们查看它的顶层结构目录，以及顶层软件包中的源代码时，它们究竟是在喊“健康管理系统”“账务系统”“库存管理系统”，还是在喊：“Rails”“Spring/Hibernate”“ASP”这样的技术名词呢？

架构设计的主题

Jacobson有一个观点：软件的系统架构应该为该系统的用例提供支持。这就像住宅和图书馆的建筑计划满篇都在非常明显地凸显这些建筑的用例一样，软件系统的架构设计图也应该非常明确地凸显该应用程序会有哪些用例。

架构设计不应是基于框架来完成的。对于我们来说，框架只是一个可用的工具和手段，而不是一个架构所规范的内容。如果我们的架构是基于框架来设计的，它就不能基于我们的用例来设计了。

架构设计的核心目标

一个良好的架构设计应该围绕着用例来展开，这样的架构设计可以在脱离框架、工具以及使用环境的情况下完整地描述用例。这就好像一个住宅建筑设计的首要目标应该是满足住宅的使用需求，而不是确保一定要用砖来构建这个房子。架构师应该花费很多精力来确保该架构的设计在满足用例需要的情况下，尽可能地允许用户能自由地选择建筑材料（砖头、石料或者木材）。

而且，良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web服务以及其他与环境相关的工具。

框架应该是一个可选项，良好的架构设计应该允许用户在项目后期再决定是否采用Rails、Spring、Hibernate、Tomcat、MySQL这些工具。同时，良好的架构设计还应该让我们很容易改变这些决定。总之，良好的架构设计应该只关注用例，并能将它们与其他的周边因素隔离。

那Web呢

Web究竟是不是一种架构？如果我们的系统需要以Web形式来交付，这是否意味着我们只能采用某种系统架构？当然不是！Web只是一种交付手段——一种IO设备——这就是它在应用程序的架构设计中的角色。换句话说，应用程序采用Web方式来交付只是一个实现细节，这不应该主导整个项目的结构设计。

事实上，关于一个应用程序是否应该以Web形式来交付这件事，它本身就应该是一个被推迟和延后的决策。一个系统应该尽量保持它与交付方式之间的无关性。在不更改基础架构设计的情况下，我们应该可以将一个应用程序交付成命令行程序、Web程序、富客户端程序、Web服务程序等任何一种形式的程序。

框架是工具而不是生活信条

当然，框架通常可以是非常强大、非常有用的。但框架作者往往对自己写出的框架有着极深的信念，他们所写出来的使用手册一般都是从如何成为该框架的虔诚信徒的角度来描绘如何使用这个框架的。甚至这些框架的使用者所写的教程也会出现这种传教士模式。他们会告诉你某个框架是能包揽一切、超越一切、解决一切问题的存在。

这不应该成为你的观点

我们一定要带着怀疑的态度审视每一个框架。是的，采用框架可能会很有帮助，但采用它们的成本呢？我们一定要懂得权衡如何使用一个框架，如何保护自己。无论如何，我们需要仔细考虑如何能保持对系统用例的关注，避免让框架主导我们的架构设计。

可测试的架构设计

如果系统架构的所有设计都是围绕着用例来展开的，并且在使用框架的问题上保持谨慎的态度，那么我们就应该可以在不依赖任何框架的情况下针对这些用例进行单元测试。

另外，我们在运行测试的时候不应该运行Web服务，也不应该需要连接数据库。我们测试的应该只是一个简单的业务实体对象，没有任何与框架、数据库相关的依赖关系。总而言之，我们应该通过用例对象来调度业务实体对象，确保所有的测试都不需要依赖框架。

跳出陷阱的问答

一个系统的架构应该着重于展示系统本身的设计，而并非该系统所使用的框架。如果我们要构建的是一个医疗系统，新来的程序员第一次看到其源码时就应该知道这是一个医疗系统。新来的程序员应该先了解该系统的用例，而非系统的交付方式。

他们可能会走过来问你：

“我看到了一些看起来像是模型的代码——但它们的视图和控制器在哪里？”

这时你的回答应该是：

“哦，我们现在先不考虑这些细节问题，回头再来决定应该怎么做。”

......

最好的总结

以下是对于尖叫架构的最好总结之一，他来自于国内软件架构师凌晨：

1、业务逻辑就是赚钱或省钱那部分逻辑

2、关键业务逻辑和业务数据是紧密相关的

3、它们适合放在同一个实体对象中，称之为"业务实体"。

4、业务逻辑应该是这个系统中最独立的、复用性最高的组件代码。

5、一个良好的架构应该是围绕用例来展开的。

6、可测试的系统架构。

Archi与Framework

邓辉也就archi与framework之间的区别与联系做了相应评论：

在建筑行业，除了Arhcitect外，还有个很重要的角色，叫Structural Engineer，这个角色考虑的问题是实现的经济性，Architect主要解决布局和用的问题。

在软件中，Architecture是个很含糊的概念。如果我们把范围做点局限的话，在软件中Architecture应该首先提供整个系统的Shape，这个Shape应该是由如何使用这个系统提供的，其实这个就是系统的概念模型。这个概念模型有多种呈现方式，比如物理目录结构，构成元素的名字，规则、协作方式等等。

由于在和建筑做类比时，忽略了structural engineer这个角色，所以很多软件架构在设计时，会忽略掉实现的经济性和可行性。有时，经济性和可行性会从根本上影响到系统的布局和使用，这个在建筑行业经常发生。

可以这样说，架构的设计有两个层面，一个逻辑层面，一个物理层面。逻辑层面考虑以用为导向系统的shape，可以脱离具体的部署环境。在物理层面要考虑实现的经济性和可行性，必须考虑实现时的约束。在做架构设计时，一定要在这两个层面不断震荡，才能形成真正好的架构。

Framework只是个在实现时可供选择的工具而已，和libray没啥本质的区别，相反其侵入性要远大于libray。

物理设计会影响逻辑层设计的决策，但是这两个层次要分离，这样才是好的设计。

框架是实现，架构设计模式是思路，没有可比性。

框架和库没啥区别，都是完成某种任务的实现工具，只是框架试图通过对某个特定领域的需求进行预测来把大部分的实现决策进行固定，而预留一些hook价格应用来定制，这正是其侵入性所在，绝大多数情况下，框架都成为限制做正确的事情的障碍。 

最后我们来听听大师关于简洁架构原则的经典授课：

-->