有人可以解释软件设计和软件架构之间的区别吗？
进一步来说; 如果您告诉某人向您展示“设计”-您希望他们展示什么？“架构”也是如此。
我目前的理解是：
如我错了请纠正我。我已经提到 Wikipedia 在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
你是对的。系统的架构是它的“骨架”。它是系统的最高抽象级别。存在什么样的数据存储，模块之间如何交互，有哪些恢复系统。就像设计模式一样，也有架构模式：MVC、3 层分层设计等。
软件设计是关于设计单个模块/组件。模块 x 的职责和功能是什么？Y班的？它能做什么，不能做什么？可以使用哪些设计模式？
所以简而言之，软件架构更多的是关于整个系统的设计，而软件设计则强调模块/组件/类级别。
在SDLC（软件开发生命周期）的某些描述中，它们是可互换的，但共识是它们是不同的。它们同时是：不同的 (1)阶段，(2)责任范围，以及 (3)决策级别。
由于不同的原因， 这两个阶段似乎融合在一起。
即使责任的阶段或领域混合在一起并发生在所有地方，知道正在发生的决策级别总是很好的。（我们可以一直这样下去。我试图将其保留为摘要。）我将结束：即使您的项目似乎没有正式的架构或设计阶段/AOR/文档，无论是否有人在，它都在发生有意识地做或不做。如果没有人决定做架构，那么就会发生一个可能很糟糕的默认架构。设计同上。如果没有代表它们的正式阶段，这些概念几乎更重要。
建筑是战略性的，而设计是战术性的。
架构包括框架、工具、编程范式、基于组件的软件工程标准、高级原则……
而设计是一项关注局部约束的活动，例如设计模式、编程习惯和重构。
当我自己在寻找建筑和设计之间的简单区别时，我发现了这一点；
您如何看待这种看待它们的方式：
体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。
设计是指为显示系统或对象在制造之前的外观和功能或工作原理而制作的计划或图纸。
如果您正在“构建”一个组件，那么您就是在定义它在更大系统中的行为方式。
如果您正在“设计”相同的组件，那么您就是在定义它在内部的行为方式。
所有架构都是设计，但并非所有设计都是架构。
What部分是设计，How是具体实现，是架构的What交集How。
用于区分建筑和设计的图像：
还有一些设计决策，在架构上并不重要，即不属于设计的架构分支。例如，某些组件的内部设计决策，如算法的选择、数据结构的选择等。
任何在其组件边界之外不可见的设计决策都是组件的内部设计，并且是非架构的。这些是系统架构师将留给模块设计人员或实施团队的设计决策，只要他们的设计不破坏系统级架构施加的架构约束。
给出很好类比的链接
用我自己的话来说，我会说你是对的；
架构是将系统需求分配给系统元素。关于架构的四个陈述：
当系统的复杂性被细分时，架构是必不可少的工程步骤。
示例：想想你的房子，你的厨房不需要建筑师（只涉及一个元素），但整个建筑需要一些交互定义，比如门和屋顶。
设计是功能（提议的）实现的信息表示。它旨在征求反馈并与利益相关者进行讨论。这可能是一种很好的做法，但不是必不可少的工程步骤。
很高兴在安装厨房之前看到厨房设计，但这对于烹饪要求并不是必需的：
如果我考虑一下，您可以说：
我的提醒：
我认为我们应该使用以下规则来确定何时谈论设计与架构：如果您创建的软件图片的元素可以一对一地映射到编程语言的句法结构，那么就是设计，否则就是架构。
因此，例如，如果您正在查看类图或序列图，则可以使用类语法结构将类及其关系映射到面向对象的编程语言。这显然是设计。此外，这可能会导致本次讨论与您将用于实现软件系统的编程语言有关。如果您使用 Java，则适用前面的示例，因为 Java 是一种面向对象的编程语言。如果你想出一个显示包及其依赖关系的图表，那也是设计。您可以将元素（在本例中为包）映射到 Java 语法结构。
现在，假设你的 Java 应用程序被划分为模块，每个模块是一组包（表示为一个 jar 文件部署单元），并且呈现给你一个包含模块及其依赖关系的图表，那就是架构。在 Java 中（至少在 Java 7 之前）没有办法将模块（一组包）映射到语法结构。您可能还会注意到，此图代表了您的软件模型抽象级别更高的一步。上面的任何图（粗粒度）都是包图，表示使用 Java 编程语言进行开发时的架构视图。另一方面，如果您在 Modula-2 中进行开发，那么，模块图代表一个设计。
（来自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段）
就个人而言，我喜欢这个：
“设计师关心的是用户按下按钮时会发生什么，而架构师关心的是一万用户按下按钮时会发生什么。”
SCEA for Java™ EE 学习指南，作者 Mark Cade 和 Humphrey Sheil
我同意许多解释；本质上，我们正在认识到软件系统的架构设计和详细设计之间的区别。
虽然设计者的目标是在规范中尽可能精确和具体，因为这将是开发所必需的；架构师的主要目标是指定系统的结构和全局行为，这与详细设计开始时的要求一样多。
一个好的架构师会防止超规范——架构不能被过度指定，但足够了，（架构）决策仅针对存在处理成本最高风险的方面建立，并有效地提供一个框架（“共性”），其中可以进行详细设计，即局部功能的可变性。
事实上，架构过程或生命周期只是遵循这个主题——足够的抽象级别来概述（架构上）重要业务需求的结构，并将更多细节留给设计阶段以获得更具体的可交付成果。
建筑就是设计，但并非所有设计都是建筑。因此，严格来说，尝试区分建筑设计和非建筑设计会更有意义。有什么区别？这取决于！每个软件架构师可能有不同的答案（ymmv！）。我们开发我们的启发式方法来得出一个答案，例如“类图是架构，序列图是设计”。有关更多信息，请参阅DSA 书。
通常说架构比设计处于更高的抽象级别，或者架构是逻辑的而设计是物理的。但是这个概念，尽管被普遍接受，在实践中是无用的。你在哪里划清高抽象或低抽象，逻辑和物理之间的界限？这取决于！
所以，我的建议是：
说了这么多……我们需要问的一个更相关的问题是：多少设计才足够？也就是说，我什么时候应该停止描述设计（在图表或散文中）并应该继续编码？
是的，这听起来对我来说是正确的。设计就是你要做的事情，而架构是将设计的点点滴滴结合在一起的方式。它可能与语言无关，但通常会指定要使用的技术，即 LAMP v Windows、Web Service v RPC。
好问题......虽然它们之间的界限几乎不是一条清晰的界限，恕我直言，如果你同时使用这两个术语，那么架构包含更多关于如何构建或构建某些东西的技术或结构决策，尤其是那些将很难做出的决定（或更难）一旦实现就改变，而设计包含那些以后容易改变的决定（如方法名称、类<->文件组织结构、设计模式、是否使用单例或静态类来解决某些特定问题等）和/或影响系统或应用程序的外观或美学方面的那些（人机界面、易用性、外观和感觉等）
我像 Patrick Karcher 一样看待建筑——大局观。例如，您可以为建筑物提供架构，查看其结构支撑、窗户、出入口、排水等。但您尚未“设计”楼层布局、隔间位置等。
因此，虽然您已经设计了建筑物，但您还没有设计每个办公室的布局。我认为软件也是如此。
您可以将设计布局视为“设计布局”...
相当主观，但我的看法：
架构 系统的整体设计，包括与其他系统的交互、硬件要求、整体组件设计和数据流。
设计 整个系统中组件的组织和流程。这还将包括用于与其他组件交互的组件 API。
软件架构“关心的问题……超出了计算的算法和数据结构。
架构特别不是关于......实现的细节（例如，算法和数据结构）。架构设计涉及比OOD“（面向对象设计）通常提供的更丰富的抽象集合。
设计关注设计元素的模块化和详细接口、它们的算法和过程，以及支持架构和满足需求所需的数据类型。
“架构”通常仅用作“设计”的同义词（有时前面带有形容词“高级”）。许多人将“架构模式”一词用作“设计模式”的同义词。</p>
看看这个链接。
架构：
结构设计工作在更高的抽象层次，实现对系统的技术上重要的要求。该架构为进一步的设计奠定了基础。
设计：
通过每个抽象层的迭代过程来填充架构所没有的东西的艺术。
我真的很喜欢这篇论文，因为它是关于将架构与设计分开的经验法则：
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
它被称为内涵/局部性假设。关于非本地和内涵的软件性质的陈述是架构性的。局部的和内涵的陈述是设计的。
...很久以前，在一个遥远的地方，哲学家们担心一与多之间的区别。建筑是关于关系的，这需要很多。建筑有组件。设计是关于内容的，这需要内容。设计具有属性、品质、特征。我们通常认为设计是在架构中。二元思维赋予了许多原始的东西。但建筑也在设计之中。这就是我们如何选择看待我们面前的事物——一个或多个。
当您需要将更高架构级别识别的业务和功能投射到应用程序中时，最好在系统级别使用软件架构。
例如，您的业务是关于交易者的“盈亏”，您的主要职能涉及“投资组合评估”和“风险计算”。
但是当软件架构师详细介绍他的解决方案时，他会意识到：
“投资组合评估”不能只是一种应用。它需要在可管理的项目中进行改进，例如：
（因为涉及的操作非常庞大，需要在多台计算机之间拆分，同时仍然通过一个通用的 GUI 随时进行监控）
a 软件设计将检查不同的应用程序、它们的技术关系和它们的内部子组件。
它将生成最后一个架构层（“技术架构”）工作所需的规范（在技术框架或横向组件方面），并为项目团队（更面向业务功能的实现）开始他们各自的项目。
如果有人建造了一艘船，那么发动机、船体、电路等将是他的“建筑元素”。对他来说，发动机制造将是“设计工作”。
如果他随后将引擎的构建委托给另一个团队，他们将创建一个“引擎架构”......
所以 - 这取决于抽象或细节的水平。一个人的建筑可能是另一个人的设计！
架构是“难以改变的设计决策”。
在使用 TDD 之后，这实际上意味着您的设计一直在变化，我经常发现自己在这个问题上苦苦挣扎。上述定义摘自Martin Fowler的企业应用程序架构模式
这意味着架构取决于系统的语言、框架和领域。如果您可以在 5 分钟内从 Java 类中提取一个接口，那么它不再是架构决策。
悬崖笔记版本：
设计：根据所需产品的规格实施解决方案。
架构：支持您的设计的基础/工具/基础设施/组件。
这是一个相当广泛的问题，会引起很多回应。
架构是用于构建系统的设计模式的集合。
我猜设计是用来把所有这些结合在一起的创造力？
软件设计的历史更长，而软件架构这个术语只有 20 年的历史。因此，它现在正在经历成长的痛苦。
学者们倾向于将架构视为更大的软件设计领域的一部分。尽管人们越来越认识到 Arch 是它自己的一个领域。
从业者倾向于将 Arch 视为具有战略意义的高级设计决策，并且在项目中撤消成本可能很高。
Arch 和设计之间的确切界限取决于软件领域。例如，在 Web 应用程序领域，分层架构目前最流行（业务逻辑层、数据访问层等）。该 Arch 的较低级别部分被认为是设计（类图、方法签名等）。 ) 这在嵌入式系统、操作系统、编译器等领域会有不同的定义。
架构是高级、抽象和逻辑设计，而软件设计是低级、详细和物理设计。
我喜欢 Roy Thomas Fielding 在他的论文中关于什么是软件架构的定义和解释： 架构风格和基于网络的软件架构的设计
软件架构是软件系统在其运行的某个阶段的运行时元素的抽象。一个系统可能由许多抽象层次和许多操作阶段组成，每个阶段都有自己的软件架构。
他强调“运行时元素”和“抽象级别”。
设计：了解模块，模块之间的关系，每个模块的功能，类及其成员函数，每个模块相互通信的接口。
架构：架构是软件系统的整体结构。所有模块、类和组件都执行不同的任务，并会给出独特的结果。
例如：有一个房子有 5 个房间。还有连接浴室。厨房也在家里。所以家里有不同的东西，这些东西之间有不同的关系。所以这都是关于一个家的“设计”。
当你从房子外面看时，你看到的整个结构都是关于建筑的。
对此没有明确的答案，因为“软件架构”和“软件设计”有很多定义，而且都没有规范的定义。
一个很好的思考方式是 Len Bass、Paul Clements 和 Rick Kazman 的声明“所有架构都是设计，但并非所有设计都是架构”[实践中的软件架构]。我不确定我是否完全同意这一点（因为架构可以包括其他活动），但它抓住了架构是处理关键设计子集的设计活动的本质。
我稍微轻率的定义（在SEI 定义页面上找到）是一组决策，如果做出错误的决定，会导致您的项目被取消。
几年前，Amnon Eden 和 Rick Kazman 在题为“架构、设计、实现”的研究论文中进行了将架构、设计和实现作为概念分离的有用尝试，该论文可在此处找到：http://www.sei.cmu .edu/library/assets/ICSE03-1.pdf。他们的语言非常抽象，但简单地说，架构是可以在许多情况下使用的设计，并且旨在应用于整个系统，设计是（错误）设计，可以在许多情况下使用但应用于特定部分系统，实现是特定于上下文的设计并应用于该上下文。
因此，架构决策可能是通过消息传递而不是 RPC 来集成系统的决策（因此它是可以应用于许多地方并旨在应用于整个系统的一般原则），设计决策可能是使用主/slave 系统的输入请求处理模块中的线程结构（可以在任何地方使用但在这种情况下仅在一个模块中使用的一般原则），最后，实现决策可能是将安全责任从请求路由器转移到请求管理器模块中的请求处理程序（仅与该上下文相关的决策，在该上下文中使用）。
我希望这有帮助！
建筑与设计密切相关；它们之间的主要区别实际上在于我们面对的方式。建筑面向战略、结构和目的，面向抽象。设计面向实施和实践，面向具体。
我认为架构是关于人类和/或系统的接口。例如，Web 服务合约，包括协议等，就是架构。屏幕是如何组成的，不是颜色等，而是那里有什么领域，是建筑。
设计是如何建造事物。什么框架、语言、技术等。这当然必须与考虑平台、安全性等的企业准则和限制保持一致。
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
该架构告诉您系统的布局方式。一个传统的架构模式示例是 3 层系统，您的系统被分解为表示层、业务层和数据层。
领域驱动设计促进了 4 层架构。表示层、应用层、领域层和基础设施层。存储库模式位于领域层和基础设施层之间。你的领域模型不应该对基础设施有任何了解，也应该保持纯粹和独立于它。这就是为什么我们有存储库来调解这两个层。
存储库模式仍然是一种模式，因为它是一个可重用的解决方案并处理重复的问题。然而，只有当我们谈论架构时，存储库模式才变得相关。它在领域驱动的设计架构中有自己的角色和职责。它不是数学类型的通用解决方案，例如可以在系统的任何地方应用的抽象工厂模式。
架构是具有来自各种因素的基本原理的设计，其中最重要的是非功能性要求，例如可扩展性，当然最重要的是经验。没有理由，你就剩下简单的模式，或者怎么做。无论是在更高级别还是在班级级别进行设计，它仍然是设计。
或者换一种方式
建筑是元设计，即设计设计。您有一些已知适合特定解决方案空间的模式，您会选择哪些模式，为什么？架构是当你回答“哪个”和“为什么”时（“如何”已经由设计给出）。它当然不依赖于抽象级别，例如实现分布式会话不是类级别的任务，但是对于给定的架构，有一些设计可供选择。
同样，架构甚至反映在类级设计中。在可扩展架构下，如果您在没有考虑可扩展性因素的情况下进行类设计，通常会有所不同。为什么你必须有一个方法“BeginAsyncUpload”而不是“Upload”是一个架构决定。
有趣的是，当我们将注意力转移到更高级别的系统元素时，“哪个和为什么”的问题变得更加重要，而“如何”变得不那么相关。在另一个方向上，“如何”部分变得更加重要，也因为重复使用使其变得显而易见，例如，在抽象工厂或原型之间进行选择。
架构识别系统的基本组件，描述它们的组织以及它们如何相关以创建系统框架。
设计描述了各种组件以及如何开发它们以在系统架构提供的框架中提供所需的功能。
在我看来，架构只不过是一个愿景，收集需求并以正确的方式构建构建块
其中作为设计，构建特定块可能有 100 种解决方案，但要满足确切要求，我们需要选择正确的方法，因此选择正确的方法或算法无非是设计
架构更像是集成系统的各种功能以实现整个系统的一个目标，而设计则解决每个功能需求。
例如，以 MVVM 为例，这是一种架构模式。对于通知功能，MVVM 使用观察者模式，这又是一种设计模式，
建筑：- 建筑根据规范在建筑的各个阶段创建平面布局。
设计者：- 设计者是一种活动，它通过功能、美学和布局的外观来满足建筑计划的所有基本要求。
正如其他人也指出的那样，布置一个软件的架构实际上是做出对软件开发或执行生命周期有整体影响的主要设计决策；所以简单的架构只是高级设计。
即使架构决策不影响所有组件（因此是本地的），它仍然必须是全局相关的，即它以某种方式影响整个系统；否则只是一个本地设计决策。
不过我想指出的是，与架构相关的一个更相关的问题可能是 Hennessy & Patterson 在计算机架构中定义的架构与组织。基于此，我们可以将架构视为系统的数据模型（输入/输出、状态）抽象，将组织视为在实施（软件开发）过程中做出的典型设计决策。
以下是可以更详细地解释体系结构的参考资料和软件体系结构的 UML 图列表。（我找不到用于软件设计的 UML 图列表）
即使在发布了这个答案之后，我自己也不清楚哪个图表用于架构，哪个图表用于设计:)。Grady Booch 在他的幻灯片 #58 中指出，类、接口和协作是设计视图的一部分，而这个设计视图是架构视图之一！！！