Question

如果架构是关于结构和愿景的，那设计又是什么？如果你在创建一个解决问题的方案，这不就是设计吗？如果确实如此，那设计和架构有什么区别？

找出区别

对于架构和设计的区别，格雷迪•布奇（Grady Booch）有一个常被引用的定义，可以很好地回答这个问题。在On Design1一文中，他说道：

1原文给出的链接 http://www.handbookofsoftwarearchitecture.com/index.jsp?page=Blog&part=2006 已失效，可访问 https://www.ibm.com/developerworks/community/blogs/gradybooch/entry/on_design?lang=en阅读文章。——译者注

作为名词，设计是指一个系统内命名的（尽管有时无法命名）结构或行为，解决或有助于解决该系统的一个或多个问题。因而设计代表了潜在的决策空间中的一个点。

思考任何一个需要解决的问题，可能都有101种方法。以你目前的软件项目为例，要实现同一目标，可能有多种不同的技术、部署平台和设计方法可选。即使是设计软件系统，你的团队也只是从潜在决策空间里的很多个点中选择一个。

格雷迪还说：

所有架构都是设计，但并非所有设计都是架构。

这很有道理，因为创建一个解决方案本质上就是一次设计练习。然而，出于某些原因，有一个区别使得并非所有设计都是“架构”，对此他声明：

架构反映了使一个系统成型的重要设计决策，而重要性则通过改变的成本来衡量。

从本质上讲，格雷迪认为重要决策即“架构”，其他的都是“设计”。在现实世界中，架构和设计的区别并不明显，但该定义确实为我们提供了一个基准，去思考在我们的软件系统中哪些可能是重要的（或者说“架构的”）。比如说，这可能包括：

系统的形态（例如，客户端-服务器、基于Web、原生移动客户端、分布式、异步，等等）；

软件系统的结构（例如，组件、层、交互，等等）；

技术选择（即编程语言、部署平台，等等）；

框架选择（例如，Web MVC2框架、持久性/ORM3框架，等等）；

设计方法/模式选择（例如，针对性能、可伸缩性、可用性等的方法）。

2Model-View-Controller，模型-视图-控制器。——译者注

3Object-Relational Mapping，对象关系映射。——译者注

架构决策不可能轻易反悔，那会大费周章。或者说直白点，架构决策很难在一个下午就完成重构。

理解意义

后退一步想想哪些对你的软件系统很重要，这往往是值得的。例如，很多团队使用关系型数据库，这个选择可能被认为很重要。为了减少在数据库技术变化时必要的返工量，很多团队会使用Hibernate或Entity Framework这样的ORM框架。引入额外的ORM层使得数据库操作能与代码的其他部分解耦，而且理论上，不用花费很多精力就能独立地切换数据库。

引入额外层的决策是将某个部分从软件系统中解耦的经典技术，促进了低耦合、高内聚和更好的关注点分离。此外，有了ORM以后，可能一个下午就完成了数据库的切换。从这一点来说，从架构上它不会再被看作是重要的。

然而，当数据库的选择可能不再被当作重要决策时，通过引入额外层实现解耦就应该是重要决策。如果你想知道为什么，试想把你当前所用的ORM或Web MVC框架完全替换成另一个，要花多长时间。当然，你可以在所选的ORM上再添加其他层，以隔离业务逻辑，并提供轻松替换ORM的敏捷性。但是，你又做出了另一个重要决策：引入了额外的分层、复杂性和成本。

尽管“重要决策”没法彻底消失，但能通过架构分层等多种策略来改变。软件系统架构流程的一部分就是搞清楚哪些是重要的及为什么。