体系结构确定了系统的基本组件，描述了它们的组织，以及它们与创建系统框架的关系。

设计描述了各种组件，以及应该如何在系统架构提供的框架中开发它们以提供所需的功能。

用我自己的话来说，你是对的;

体系结构是将系统需求分配给系统元素。关于架构的四个陈述:

它可以引入非功能性需求，如语言或模式。 它定义了组件、接口、时序等之间的交互。 它不应该引入新的功能， 它将系统要执行的(设计的)功能分配给元素。

当对系统的复杂性进行细分时，体系结构是必不可少的工程步骤。

例如:想想你的房子，你的厨房不需要建筑师(只涉及一个元素)，但整个建筑需要一些交互定义，比如门和屋顶。

设计是对功能(提议的)实现的一种信息表示。它旨在获得反馈，并与利益相关者进行讨论。这可能是一个很好的实践，但不是一个必要的工程步骤。

在厨房安装之前，最好能看到厨房的设计，但对于烹饪要求来说不是必需的:

如果我想一下，你可以这样说:

架构是为公众/工程师在更详细的抽象层次上设计的 设计是在一个不太详细的抽象层次上面向公众的

Cliff Notes版本:

设计:根据所需产品的规格实现解决方案。

架构:支持设计的基础/工具/基础设施/组件。

这是一个相当宽泛的问题，会引起很多人的回应。

建筑就是设计，但并非所有的设计都是建筑。因此，严格地说，尝试区分架构设计和非架构设计会更有意义。有什么区别呢?视情况而定!每个软件架构师可能有不同的答案(ymmv!)我们开发我们的启发式来提出一个答案，例如“类图是架构，序列图是设计”。有关更多信息，请参阅DSA书籍。

人们常说，架构比设计处于更高的抽象级别，或者架构是逻辑的，而设计是物理的。但这种观念虽然被普遍接受，但在实践中却毫无用处。在高抽象和低抽象之间，逻辑和物理之间，你的界线在哪里?视情况而定!

所以，我的建议是:

create a single design document. name this design document the way you want or, better, the way the readers are more accustomed to. Examples: "Software Architecture", "Software Design Specification". break this document into views and keep in mind you can create a view as a refinement of another view. make the views in the document navigable by adding cross-references or hyperlinks then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details. you may want to take a look at an example of multi-view architecture document (here).

说了这么多……我们需要问的一个更相关的问题是:多少设计才足够?也就是说，我什么时候应该停止描述设计(用图表或散文)，而应该转向编码?

是的，对我来说听起来不错。设计是你要做的事情，而架构是将设计的各个部分连接在一起的方式。它可以是语言不可知的，但通常会指定要使用的技术，例如LAMP vs Windows, Web服务vs RPC。

以下是可能更详细地解释体系结构的参考资料和软件体系结构的UML图列表。(我找不到用于软件设计的UML图列表)

Grady Booch

在架构模型中使用UML 2图

UML图的分类

UML图的分类

即使在发布了这个答案之后，我自己也不清楚哪个图是用于架构的，哪个图是用于设计的:)。Grady Booch在他的第58张幻灯片中指出，类、接口和协作是设计视图的一部分，而这个设计视图是架构视图的一部分!!