Software Design vs. Software Architecture
有人能解释软件设计和软件架构之间的区别吗？
更具体地说，如果你告诉某人向你展示"设计"，你希望他们展示什么？"建筑"也是如此。
我目前的理解是：
- 设计：UML图/流程图/系统特定模块/部分的简单线框(用于UI)
- 体系结构：组件图(显示系统的不同模块之间以及其他系统之间的通信方式)、要使用的语言、模式…？
如果我错了就纠正我。我提到过维基百科在http://en.wikipedia.org/wiki/software_design和http://en.wikipedia.org/wiki/software_architecture上有文章，但我不确定我是否正确理解了它们。
你说得对是的。系统的体系结构就是它的"骨架"。它是系统的最高抽象级别。存在哪种数据存储，模块之间如何交互，有哪些恢复系统。和设计模式一样，也有架构模式：MVC、三层分层设计等。
软件设计是指设计单个模块/组件。模块X的职责、功能是什么？Y级的？它能做什么，不能做什么？可以使用什么设计模式？
因此简而言之，软件体系结构更多的是整个系统的设计，而软件设计则强调模块/组件/类的层次。
在对SDLC(软件开发生命周期)的一些描述中，它们是可互换的，但其后果是它们是不同的。它们同时存在：不同的(1)阶段，(2)责任领域，以及(3)决策水平。
- 架构是一幅更大的图景：框架、语言、范围、目标和高级方法的选择(理性、瀑布式、敏捷等)。
- 设计是一幅小图：计划如何组织代码；系统不同部分之间的合同看起来如何；项目方法和目标的持续实施。规范是在这个阶段编写的。
这两个阶段似乎因不同的原因而融合在一起。
即使责任的各个阶段或领域融合在一起并在各地发生，了解正在发生的决策水平总是很好的。(我们可以一直这样下去。我试着做一个总结。)我将以：即使你的项目似乎没有正式的架构或设计阶段/AOR/Documentaiton，不管有没有人有意识地做，它都在发生。如果没有人决定做体系结构，那么会出现一个可能很差的默认体系结构。设计同上。如果没有正式的阶段来表示这些概念，那么这些概念就几乎更重要了。
架构是战略的，而设计是战术的。
体系结构包括框架、工具、编程范例、基于组件的软件工程标准、高级原则。
而设计是一个与局部约束有关的活动，例如设计模式、编程习惯和重构。
我发现这是因为我在寻找建筑和设计之间的简单区别；你认为这种看待他们的方式是什么？
- 建筑就是我们正在建造的"什么"；
- 设计是"如何"建造的；
建筑是指计算机或计算机系统的概念结构和逻辑组织。
设计是一个计划或绘图，在制作之前显示一个系统或物体的设计、功能或工作。
如果你是"建筑师"的一个组成部分，你就可以定义它是如何在大系统中。
如果你是"设计"同一部件，你就确定它是如何在内部。
All architecture is design but NOT all design is architecture.
第一部分是设计，第二部分是具体实现和交叉点的结构。
不同建筑与设计形象
MGX1〔0〕
也有设计决定，这不是建筑意义，我不属于设计的建筑分支。例如，有些组成部分的内部设计决定，如算法选择、数据结构选择等。
任何设计决定，如果在其组成部分边界外看不到，则是内部设计，而非建筑设计。这些是一个系统的设计决定，一个系统的建筑师将留在模块设计师的离散状态，或在他们的设计不打破系统层次结构所要求的建筑限制的情况下，执行小组将留在较长的时间。
给了好模拟的链接
用我自己的话说，我会说你是对的；
体系结构是将系统需求分配给系统元素。关于架构的四个陈述：
当系统的复杂性被细分时，体系结构是一个必不可少的工程步骤。
举个例子：想想你的房子，你的厨房不需要一个建筑师(只涉及一个元素)，但是整个建筑需要一些交互定义，比如门和屋顶。
设计是功能实现(建议)的信息表示。它旨在引起反馈并与利益相关者讨论。这可能是一个很好的实践，但不是一个必要的工程步骤。
在安装厨房之前，很高兴看到厨房设计，但对于烹饪要求来说，这并不重要：
如果我考虑一下，你可以说：
- 架构是面向更详细抽象级别的公共/工程师的
- 设计是在一个不太详细的抽象层次上面向公众的。
我的提醒：
- 我们可以不用问别人就改变设计
- 如果我们改变架构，我们需要将其传达给某人(团队、客户、利益相关者等)。
我认为我们应该使用下面的规则来确定何时讨论设计与体系结构：如果您创建的软件图片的元素可以映射到一个到一个编程语言语法结构，那么就是设计，如果不是体系结构。
因此，例如，如果您看到一个类图或序列图，您可以使用类语法结构将一个类及其关系映射到面向对象的编程语言。这显然是设计。此外，这可能会使讨论与您将用于实现软件系统的编程语言有关系。如果使用Java，则前面的示例适用，因为Java是面向对象的编程语言。如果您想出一个显示包及其依赖关系的图表，那也是设计。可以将元素(在此情况下的包)映射到Java语法结构。
现在，假设您的Java应用程序被划分为模块，每个模块都是一组包(表示为JAR文件部署单元)，并且呈现一个包含模块及其依赖关系的图，即架构。Java(至少在Java 7之前)没有办法将模块(一组包)映射到句法结构。您可能还注意到，这个图代表了软件模型抽象级别的更高一步。上面的任何图(粗粒度大于封装图)，表示在Java编程语言中开发时的体系结构视图。另一方面，如果您是在模块2中开发的，那么模块图表示一种设计。
(来自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段)
我同意许多解释；本质上，我们正在认识到体系结构设计和软件系统的详细设计之间的区别。
虽然设计者的目标是在规范中像开发所必需的那样精确和具体；但是架构师的基本目标是在详细设计开始时尽可能详细地说明系统的结构和全局行为。
一个好的架构师会阻止超规范——架构不能被过度指定，而仅仅是足够的，(架构)决策只针对存在最昂贵风险的方面制定，并有效地提供一个框架("共性")，在这个框架内，详细的设计可以被处理，即本地的可变性。功能。
实际上，架构(architecture)过程或生命周期只是遵循这个主题——足够的抽象级别来概括(架构上)重要业务需求的结构，并将更多细节留给设计阶段，以获得更具体的可交付成果。
建筑就是设计，但并非所有的设计都是建筑。因此，严格来说，区分建筑设计和非建筑设计更有意义。有什么区别？这要看情况！每个软件架构师可能有不同的答案(ymmv！).我们开发了我们的启发式方法来给出一个答案，比如"类图是架构，序列图是设计"。更多信息，请参阅DSA手册。
通常说体系结构比设计处于更高的抽象级别，或者说体系结构是逻辑的，设计是物理的。但这个概念，尽管被普遍接受，但实际上是无用的。在高抽象或低抽象、逻辑抽象和物理抽象之间，你从哪里划出界限？这要看情况！
所以，我的建议是：
- 创建单个设计文档。
- 以您想要的方式命名此设计文档，或者更好地命名为读者更习惯的方式。示例："软件架构"、"软件设计规范"。
- 将此文档拆分为视图，并记住您可以创建一个视图作为另一个视图的优化。
- 通过添加交叉引用或超链接使文档中的视图可导航
- 然后，您将看到更高级别的视图，显示设计的广泛但浅显的概述，并且更接近显示狭窄但更深入的设计细节的实现视图。
- 您可能想看看多视图体系结构文档的一个示例(这里)。
说了这么多……我们需要问的一个更相关的问题是：多少设计是足够的？也就是说，我应该什么时候停止描述设计(用图表或散文)并继续编码？
就我个人而言，我喜欢这个：
设计师关心的是当用户按下一个按钮时会发生什么，而架构师关心的是当一万个用户按下一个按钮时会发生什么。
Java的SCEA？马克·卡德和汉弗莱·谢尔的研究指南
很主观，但我认为：
建筑系统的总体设计，包括与其他系统的交互、硬件需求、总体组件设计和数据流。
设计整个系统中一个组件的组织和流程。这还包括组件的API，用于与其他组件交互。
我真的很喜欢这篇文章，因为它有一个区分建筑和设计的经验法则：
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design-ieesw.pdf
这被称为强度/局部假设。非本地和内涵的软件性质声明是体系结构的。地方性和内涵性的陈述是设计。
是的，听起来不错。设计就是你要做的，而架构就是设计的各个部分结合在一起的方式。它可以是语言不可知论者，但通常会指定要使用的技术，即lamp v windows、web service v rpc。
软件体系结构"关注的问题……超出了计算的算法和数据结构。
体系结构尤其不涉及实现的细节(例如算法和数据结构)。体系结构设计包含比通常由OOD(面向对象设计)提供的更丰富的抽象集合。
设计涉及设计元素的模块化和详细接口、算法和过程，以及支持体系结构和满足需求所需的数据类型。
"建筑"常被用作"设计"的同义词(有时前面加上形容词"高级")。许多人使用"架构模式"这个术语作为"设计模式"的同义词。
查看此链接。
定义术语体系结构、设计和实现
我和帕特里克·卡彻一样看待建筑——大局。例如，您可以为建筑提供建筑，查看其结构支撑、窗户、入口和出口、排水等，但您没有"设计"地板布局、隔间位置等。
所以，虽然你已经设计了这座大楼，但你还没有设计出每个办公室的布局。我认为软件也是如此。
您可以将设计布局视为"设计布局"，尽管……
程序或计算系统的软件体系结构是系统的结构或结构，包括软件组件、这些组件的外部可见属性以及它们之间的关系。
(摘自维基百科，http://en.wikipedia.org/wiki/software_architecture)
软件设计是一个解决问题和规划软件解决方案的过程。在确定了软件的用途和规格之后，软件开发人员将设计或雇佣设计人员来制定解决方案的计划。它包括低级组件和算法实现问题以及体系结构视图。
(摘自维基百科，http://en.wikipedia.org/wiki/software_design)
我自己说得再好不过了：)
好问题…虽然它们之间的界限不是一条清晰的界线，但是，imho，如果您同时使用这两个术语，那么架构包含了更多关于如何构建或构建某个东西的技术或结构决策，尤其是那些一旦实施就难以(或更难)更改的决策，而设计则包含了那些R以后很容易更改(例如方法名、类<->文件组织结构、设计模式、是否使用单例类或静态类来解决某些特定问题等)和/或影响系统或应用程序的外观或美学方面的内容(人机界面、易用性、外观和感觉等)。
建筑学：结构设计工作在更高的抽象层次上，实现了对系统的重要技术要求。该体系结构为进一步的设计奠定了基础。
设计：在每一个抽象层上通过迭代过程来填充体系结构所不具备的功能的艺术。
……很久以前，在一个遥远的地方，哲学家们担心一与多的区别。架构是关于关系的，这需要很多。体系结构包含组件。设计是关于内容的，这需要内容。设计具有特性、质量和特点。我们通常认为设计是在体系结构中进行的。二元论认为许多是原始的。但是架构也在设计中。这就是我们选择如何看待我们面前的一切——一个或多个。
架构是"难以改变的设计决策"。
在与TDD合作之后，这实际上意味着你的设计一直在变化，我经常发现自己在这个问题上挣扎。上面的定义是由MartinFowler从企业应用程序体系结构模式中提取的。
这意味着体系结构依赖于语言、框架和系统的领域。如果您可以在5分钟内从Java类中提取接口，则不再是架构决策。
如果有人建造了一艘船，那么发动机、船体、电路等将是他的"建筑元素"。对他来说，发动机的构造将是"设计工作"。
如果他将引擎的构造委托给另一个团队，他们将创建一个"引擎架构"…
所以-这取决于抽象或细节的层次。一个人的建筑可能是另一个人的设计！
当您需要将业务和功能按更高的体系结构级别标识到应用程序中时，软件体系结构最好在系统级别使用。
例如，您的业务是关于交易员的"损益"，您的主要功能包括"投资组合评估"和"风险计算"。
但是当一个软件架构师详细描述他的解决方案时，他会意识到：
"投资组合评估"不能只是一个应用程序。它需要在可管理的项目中进行改进，例如：
- GUI
- 发射装置
- 调度员
- …
(因为所涉及的操作非常庞大，所以需要在多台计算机之间进行拆分，同时始终通过一个通用图形用户界面进行监控)
软件设计将检查不同的应用程序、它们的技术关系以及它们的内部子组件。它将为最后一个体系结构层(即"技术体系结构")制定所需的规范，以便进行工作(在技术框架或横向组件方面)，并为项目团队(更注重业务功能的实现)开始各自的项目。
体系结构是高层次、抽象和逻辑的设计，而软件设计是低层次、详细和物理的设计。
建筑和设计是密切相关的；它们之间的主要区别在于我们面对的是哪种方式。体系结构面向战略、结构和目的，面向抽象。设计面向实现和实践，面向具体。
对此没有明确的答案，因为"软件体系结构"和"软件设计"有相当多的定义，也没有一个规范的定义。
一个好的思考方法是Len Bass，Paul Clements和Rick Kazman的陈述"所有架构都是设计，但并非所有设计都是架构"[实践中的软件架构]。我不确定我是否完全同意这一点(因为架构可以包括其他活动)，但它抓住了架构是处理设计关键子集的设计活动的本质。
我有点轻率的定义(在SEI定义页面上找到)是，这是一组决策，如果错误地做出，会导致项目被取消。
几年前，Amnon Eden和Rick Kazman在一篇题为"架构、设计、实现"的研究论文中做了一次将架构、设计和实现分离为概念的有益尝试，该论文可在以下网址找到：http://www.sei.cmu.edu/library/assets/icse03-1.pdf。他们的语言非常抽象，但简单地说，体系结构是一种设计，可以在许多上下文中使用，并打算在整个系统中应用；设计是(err)设计，可以在许多上下文中使用，但应用于系统的特定部分；实现是特定于上下文的设计，并应用于该上下文。文本。
因此，体系结构决策可以是通过消息传递而不是通过RPC集成系统的决策(因此，这是一个可以在许多地方应用的通用原则，并打算应用于整个系统)，设计决策可以是在系统的输入请求处理模块中使用主/从线程结构(一个通用的PrinceIPLE可以在任何地方使用，但在本例中，它仅在一个模块中使用)，最后，实现决策可能是将安全责任从请求路由器转移到请求管理器模块中的请求处理程序(仅与该上下文相关的决策，在该上下文中使用)。
希望这有帮助！
软件设计有着更长的历史，而术语软件架构只有20年的历史。因此，它现在正在经历成长的痛苦。
学术界倾向于将架构视为软件设计更大领域的一部分。尽管人们越来越认识到拱门是它自己的领域。
从业者倾向于将arch视为高级别的设计决策，这些决策具有战略意义，并且在要撤消的项目中成本高昂。
架构和设计之间的确切界限取决于软件领域。例如，在Web应用领域，分层体系结构目前最受欢迎(biz逻辑层、数据访问层等)。该架构的较低级别部分被认为是设计(类图、方法签名等)。这将在嵌入式系统、操作系统、C.走私者等。
我喜欢Roy Thomas Fielding在他的论文中对什么是软件架构的定义和解释：体系结构风格与基于网络的软件体系结构设计
A software architecture is an abstraction of the run-time elements of a software system during some phase of its operation. A system may be composed of many levels of abstraction and many phases of operation, each with its own software architecture.
他强调"运行时元素"和"抽象层次"。
克里夫笔记版本：
设计：根据所需产品的规范实现解决方案。
架构：支持设计的基础/工具/基础设施/组件。
这是一个相当广泛的问题，会引起很多人的反应。
体系结构是构建系统的设计模式的集合。
我想设计是把所有这些结合在一起的创造力吗？
此外，请参阅：http://en.wikipedia.org/wiki/4%2b1_建筑视图模型
设计：了解模块、模块之间的关系、每个模块的功能、类及其成员函数、每个模块之间相互通信的接口。
体系结构：体系结构是软件系统的整个结构。所有的模块、类和组件执行不同的任务，并将给出一个独特的结果。
例如：有一个家有5个房间。还有附加的浴室。家里也有厨房。所以家里有不同的东西，所有的东西都有不同的关系。所以这都是关于一个家的"设计"。
当你从房子外面看的时候，你看到的整个结构都是关于建筑的。
正如其他人所指出的，设计一个软件的体系结构实际上是在做出对软件开发或执行生命周期有总体影响的主要设计决策；所以简单的体系结构只是高层次的设计。
即使架构(architecture)决策不影响所有组件(因此是本地的)，它也必须是全局相关的，即它以某种方式影响整个系统；否则，它只是一个本地设计决策。
不过，我想指出的是，与体系结构相关的一个更为相关的问题可能是体系结构与组织，正如Hennessy&Patterson在计算机体系结构中所定义的那样。基于此，我们可以将架构看作是系统和组织的数据模型(输入/输出、状态)抽象，是在实现(软件开发)过程中所做的典型设计决策。
建筑：建筑在建筑的各个阶段创建平面布局。符合规范要求。
设计师：设计师是指能够满足建筑设计图所有基本要求的活动，其功能性、准确性和对布局的理解。
在我看来，架构只不过是一个愿景，收集需求并以正确的方式构建构建块。
在设计中，构造特定的块可能有100个解，但为了满足精确的要求，我们需要选择正确的方法，所以选择正确的方法或算法只是设计。
体系结构确定了系统的基本组件，描述了它们的组织以及它们如何与创建系统框架相关。
设计描述了各种组件，以及如何开发它们，以便在系统架构(architecture)提供的框架中提供所需的功能。
我认为架构是关于人和/或系统的接口。对于精神错乱的人来说，Web服务契约(包括协议等)就是体系结构。一个屏幕是如何组成的，而不是颜色等，而是有哪些字段，这就是架构。
设计就是要建造的东西。什么框架、语言、技术等。当然，这必须与考虑平台、安全性等的企业指南和限制保持一致。
体系结构设计的基本原理来自各种因素，其中最重要的是非功能性需求，如可扩展性，当然最重要的是经验。如果没有基本原理，你就只剩下简单的模式，或者如何做。无论是在更高的层次上设计还是在阶级层次上设计，它仍然是设计。
或者换一种方式
建筑是元设计，即设计设计。您有一些已知的模式适合特定的解决方案空间，您会选择哪个模式，为什么？架构就是当你回答"哪一个"和"为什么"时("如何"已经由设计给出)。它当然不依赖于抽象级别，例如，实现分布式会话不是一个类级别的任务，但是有一些设计可以为给定的体系结构选择。
同样，体系结构甚至反映在类级设计中。在可伸缩架构下，如果您不考虑可伸缩性因素，那么类设计通常是不同的。为什么你必须有一个方法"beginasyncupload"和"upload"是一个架构决策。
有趣的是，当我们将焦点转向更高层次的系统元素时，"哪个和为什么"变得更重要，"如何"变得不那么重要。向另一个方向移动"如何"的部分变得更重要，这也是因为重复使用使得在抽象工厂或原型之间进行选择变得明显。
http://jinholf.tumblr.com/post/6591954772/architecture-patterns-vs-design-patterns
体系结构告诉您系统的布局。一个传统的体系结构模式示例是三层系统，其中您的系统分为表示层、业务层和数据层。
领域驱动的设计促进了4层体系结构。演示、应用程序、域和基础结构层。存储库模式位于域层和基础结构层之间。您的域模型不应该知道任何关于基础设施的信息，并且应该保持纯粹和独立于基础设施。这就是为什么我们拥有中介这两个层的存储库。
存储库模式仍然是一个模式，因为它是一个可重用的解决方案，可以处理重复出现的问题。然而，只有当我们谈论体系结构时，知识库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案，例如抽象工厂模式，可以应用于系统中的任何地方。
体系结构更像是集成系统的各种功能，以实现整个系统的一个目标，而设计则处理每个功能需求。
例如，以MVVM为例，它是一种体系结构模式。对于通知功能，MVVM使用观测器模式，而观测器模式又是一种设计模式，
以下是可以更详细地解释体系结构的参考资料和软件体系结构的UML图列表。(我找不到软件设计的UML图列表)
布奇
UML 2图表用于架构模型
UML图的分类
UML图的分类
即使在发布了这个答案之后，我自己也不清楚哪个图是用于架构的，哪个图是用于设计的。Grady Booch在他的幻灯片58中指出，类、接口和协作是设计视图的一部分，而这个设计视图是架构视图的一部分！！！！