对于架构和设计的区别，格雷迪•布奇（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 框架，等等）；
- 设计方法/模式选择（例如，针对性能、可伸缩性、可用性等的方法）。
2 Model-View-Controller，模型-视图-控制器。——译者注
3 Object-Relational Mapping，对象关系映射。——译者注
架构决策不可能轻易反悔，那会大费周章。或者说直白点，架构决策很难在一个下午就完成重构。