我同意其中的许多解释;本质上，我们认识到软件系统的架构设计和详细设计之间的区别。

虽然设计师的目标是在开发所需的规格中尽可能精确和具体;架构师本质上的目标是指定系统的结构和全局行为，就像详细设计开始时所要求的那样。

优秀的架构师会避免过度规范——架构不能过分指定，但要足够，(架构)决策只针对那些风险处理成本最高的方面建立，并有效地提供一个框架(“通用性”)，在这个框架内可以进行详细设计，即局部功能的可变性。

实际上，体系结构过程或生命周期只是遵循这个主题——足够的抽象级别来概述(体系结构上的)重要业务需求的结构，并将更多细节留给设计阶段以实现更具体的可交付成果。

在SDLC(软件开发生命周期)的一些描述中，它们是可互换的，但共识是它们是不同的。它们同时是:不同的(1)阶段，(2)责任领域，(3)决策层次。

架构是更大的图景:框架、语言、范围、目标和高级方法(Rational、瀑布式、敏捷等)的选择。 设计是更小的画面:如何组织代码的计划;系统不同部分之间的契约将会是怎样的;项目方法和目标的持续实施。规范是在这个阶段编写的。

由于不同的原因，这两个阶段似乎融合在一起。

Smaller projects often don't have enough scope to separate out planning into these to stages. A project might be a part of a larger project, and hence parts of both stages are already decided. (There are already existing databases, conventions, standards, protocols, frameworks, reusable code, etc.) Newer ways of thinking about the SDLC (see Agile methodologies) somewhat rearrange this traditional approach. Design (architecture to a lesser extent) takes place throughout the SDLC on purpose. There are often more iterations where the whole process happens over and over. Software development is complicated and difficult to plan anyway, but clients/managers/salespeople usually make it harder by changing goals and requirements mid-stream. Design and even architectural decisions must bemade later in the project whether that is the plan or not.

Even if the stages or areas of responsibility blend together and happen all over the place, it is always good to know what level of decision-making is happening. (We could go on forever with this. I'm trying to keep it a summary.) I'll end with: Even if it seems your project has no formal architectural or design stage/AOR/documentaiton, it IS happening whether anyone is consciously doing it or not. If no one decides to do architecture, then a default one happens that is probably poor. Ditto for design. These concepts are almost more important if there are no formal stages representing them.

建筑是战略的，而设计是战术的。

架构包括框架、工具、编程范例、基于组件的软件工程标准和高级原则。

而设计是一种与局部约束有关的活动，例如设计模式、编程习惯用语和重构。

我非常喜欢这篇文章，因为它提供了将建筑与设计分开的经验法则:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

这被称为内涵/局部性假说。关于软件性质的非本地和内涵的陈述是架构性的。局部的和内涵的语句是设计的。

当您需要将较高体系结构级别识别的业务和功能投射到应用程序中时，软件体系结构最好用于系统级。

例如，你的业务是关于交易员的“盈亏”，你的主要功能涉及“投资组合评估”和“风险计算”。

但是当软件架构师详细描述他的解决方案时，他会意识到:

“投资组合评估”不能只是一个应用程序。它需要在可管理的项目中进行细化，例如:

GUI 发射器 调度程序 .．.

(因为涉及的操作太大了，需要在几台计算机之间进行拆分，同时仍然可以通过一个通用的GUI随时监控)

软件设计将检查不同的应用程序，它们的技术关系和内部子组件。 它将产生最后一个体系结构层(“技术体系结构”)工作所需的规范(根据技术框架或横向组件)，以及项目团队(更面向业务功能的实现)开始各自的项目所需的规范。

架构是高层次的、抽象的、逻辑的设计，而软件设计是低层次的、详细的、物理的设计。