软件设计与软件体系结构

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

你说得对，是的。系统的架构是它的“骨架”。它是系统抽象的最高层次。有什么样的数据存储，模块之间如何交互，有什么样的恢复系统。就像设计模式一样，也有架构模式:MVC、3层分层设计等。

软件设计就是设计各个模块/组件。模块x的职责和功能是什么?Y类?它能做什么，不能做什么?可以使用哪些设计模式?

所以简而言之，软件架构更多的是整个系统的设计，而软件设计则强调模块/组件/类的层面。

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

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

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

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

• GUI
• 发射器
• 调度程序
• .．.

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

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

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

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

1. 较小的项目通常没有足够的范围将计划划分为各个阶段。
2. 一个项目可能是一个更大的项目的一部分，因此两个阶段的部分已经确定。(已经存在现有的数据库、约定、标准、协议、框架、可重用代码等)
3. 思考SDLC的新方法(参见敏捷方法)在某种程度上重新安排了这种传统方法。设计(较小程度上的体系结构)贯穿于SDLC 故意。通常有更多的迭代，整个过程发生了一遍又一遍。
4. 无论如何，软件开发都是复杂而难以规划的，但是客户/经理/销售人员通常会在开发过程中改变目标和需求，从而使其变得更加困难。设计甚至架构决策必须都是在项目的后期做出的，不管这是不是计划。

即使责任的各个阶段或领域混合在一起，并且发生在各个地方，知道正在发生什么级别的决策总是很好的。(我们可以一直这样说下去。我试着做个总结。)最后我想说:即使你的项目看起来没有正式的架构或设计阶段/AOR/文档，但无论是否有人有意识地这样做，它都在发生。如果没有人决定做架构，那么就会出现一个可能很差的默认架构。设计也是如此。如果没有正式的阶段表示它们，这些概念几乎是更重要的是。

好问题……尽管它们之间的界限并不明显，但如果你同时使用这两个术语，那么架构包含了更多关于如何构建或构造某些东西的技术或结构决策，特别是那些一旦实现就很难(或更难)更改的决策，而设计包含了那些稍后容易更改的决策(如方法名称，类<->文件组织结构，设计模式，是使用单例还是静态类来解决某些特定的问题，等等)和/或那些影响系统或应用程序的外观或美学方面的问题(人机界面，易用性，外观和感觉，等等)。

Cliff Notes版本:

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

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

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

体系结构是用于构建系统的设计模式的最终集合。

我猜设计是用来把所有这些放在一起的创造力?

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

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

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

程序或计算系统的软件体系结构是系统的结构，由软件组件、这些组件的外部可见属性以及它们之间的关系组成。

(from Wikipedia， http://en.wikipedia.org/wiki/Software_architecture)

软件设计是解决问题和规划软件解决方案的过程。在软件的目的和规格确定之后，软件开发人员将设计或雇用设计人员为解决方案制定计划。它包括低级组件和算法实现问题以及体系结构视图。

(from Wikipedia， http://en.wikipedia.org/wiki/Software_design)

我自己也说不出更好的话了:)

我像Patrick Karcher一样看待建筑——从大局出发。例如，您可以为建筑物提供架构，查看其结构支撑、窗户、入口和出口、排水等。但你并没有“设计”楼层布局、隔间位置等。

你可以把设计布局看作是“设计布局”……

非常主观，但我的观点是:

< >强架构 系统的总体设计，包括与其他系统的交互、硬件要求、总体组件设计和数据流

< >强设计 整个系统中一个组件的组织和流程。这还包括该组件与其他组件交互的API

软件体系结构“关注的问题是……超出了计算的算法和数据结构。

架构特别不是关于实现的细节(例如，算法和数据结构)。体系结构设计包含了比OOD(面向对象设计)通常提供的更丰富的抽象集合。

设计关注设计元素的模块化和详细接口，它们的算法和过程，以及支持体系结构和满足需求所需的数据类型。

“建筑”经常被用作“设计”的同义词(有时前面带有形容词“高级”)。许多人使用术语“架构模式”作为“设计模式”的同义词。

查看这个链接。

定义术语体系结构，设计和实现

软件设计有更长的历史，而软件架构这个术语只有20年的历史。因此，它正在经历成长的烦恼。

学术界倾向于将架构视为更大的软件设计领域的一部分。尽管越来越多的人认识到Arch是一个独立的领域。

实践者倾向于将Arch视为高级设计决策，具有战略性，并且在项目中撤销可能代价高昂。

Arch和设计之间的确切界限取决于软件领域。例如，在Web应用领域，分层架构是目前最受欢迎的(业务逻辑层，数据访问层等)。Arch的低层部分被认为是设计(类图，方法签名等)。在嵌入式系统，操作系统，编译器等领域，这将是不同的定义。

就我个人而言，我喜欢这个:

“设计师关心的是当一个用户按下一个按钮时会发生什么，而架构师关心的是当一万个用户按下一个按钮时会发生什么。”

SCEA Java™EE学习指南由马克凯德和汉弗莱谢尔

我认为架构是关于人类和/或系统的接口。例如，web服务契约(包括协议等)就是体系结构。一个屏幕是如何组成的，不是颜色之类的，而是有什么领域，这就是架构。

设计就是如何建造某样东西。什么框架、语言、技术等等。当然，这必须与考虑平台、安全性等的企业指导方针和限制相一致。

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

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

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

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

当系统的复杂性被细分时，体系结构是关键工程步骤。

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

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

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

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

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

http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns

架构告诉您系统是如何布局的。一个传统的体系结构模式示例是3层系统，其中系统被分解为表示层、业务层和数据层。

领域驱动的设计促进了4层架构。表示层、应用层、域层和基础结构层。存储库模式位于域层和基础结构层之间。你的领域模型不应该知道任何关于基础设施的信息，同时也应该保持纯粹并独立于基础设施。这就是为什么我们有存储库来协调这两层。

存储库模式仍然是一个模式，因为它是一个可重用的解决方案，可以处理重复出现的问题。然而，只有当我们讨论架构时，存储库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案，例如抽象工厂模式，可以应用于系统中的任何地方。

同时，参考: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model < / p >

我认为当我们讨论设计与架构时，我们应该使用下面的规则来确定:如果您创建的软件图的元素可以一一映射到编程语言的语法结构，那么就是设计，如果不是架构。

因此，例如，如果您看到一个类图或序列图，您就能够使用类语法结构将类及其关系映射到面向对象编程语言。这显然是设计。此外，这可能会使讨论与您将用于实现软件系统的编程语言有关系。如果您使用Java，前面的示例也适用，因为Java是面向对象编程语言。如果你想出一个图表来显示包和它的依赖关系，那也是设计。您可以将元素(在本例中是包)映射到Java语法结构。

现在，假设您的Java应用程序被划分为模块，每个模块是一组包(表示为一个jar文件部署单元)，并且您看到了一个包含模块及其依赖关系的图，那么，这就是体系结构。在Java中(至少在Java 7之前)没有办法将模块(一组包)映射到语法结构。您可能还注意到，这个图代表了软件模型抽象层次上的一个更高的步骤。上面的任何图(粗粒度的)一个包图，在用Java编程语言开发时表示一个体系结构视图。另一方面，如果你在Modula-2中开发，那么，一个模块图代表一个设计。

(来自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段)

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

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

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

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

Grady Booch .

用于架构模型的UML 2图

UML图的分类

UML图的分类

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

• 架构是我们正在建造的“什么”;
• 设计是我们“如何”建造;

.．.很久以前，在一个遥远的地方，哲学家们担心“一”与“多数”之间的区别。建筑是关于关系的，这需要很多。体系结构有组件。设计是关于内容的，内容需要设计。设计具有性质、品质、特点。我们通常认为设计是建筑的一部分。二元论思维将多作为原始的。但建筑也存在于设计之中。关键在于我们如何选择看待眼前的事物——是一个还是许多。

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

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

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

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

如果有人建造了一艘船，那么发动机、船体、电路等将是他的“建筑元素”。对他来说，发动机制造将是“设计工作”。

如果他将引擎的构建委托给另一个团队，他们将创建一个“引擎架构”……

这取决于抽象和细节的程度。一个人的建筑可能是另一个人的设计!

架构设计的基本原理来自于各种因素，其中最重要的是非功能性需求，比如可伸缩性，当然最重要的是经验。没有了理论基础，你就只剩下平淡的模式，或者怎么做。无论是在更高的层次上还是在类的层次上，它仍然是设计。

或者换句话说

架构是元设计，即设计设计。您有一些已知的模式适合某个解决方案空间，您会选择哪个，为什么?架构是当你回答“是哪个”和“为什么”时(“如何”已经在设计中给出了)。它当然不依赖于抽象级别，例如实现分布式会话不是一个类级别的任务，但是对于给定的体系结构有一些设计可供选择。

同样，体系结构也反映在类级设计中。在可伸缩的体系结构下，如果不考虑可伸缩性因素，类设计通常是不同的。为什么你必须有一个方法“BeginAsyncUpload”而不是“Upload”是一个架构决策。

有趣的是，当我们将注意力转移到更高层次的系统元素时，“哪个和为什么”问题变得更加重要，而“如何”变得不那么相关。从另一个方向来看，“如何”部分变得更加重要，这也是因为重复使用使得它变得很明显，例如，在抽象工厂和原型之间进行选择。

我的提醒:

• 我们可以不征求别人的意见就改变设计
• 如果我们改变架构，我们需要将其传达给某人(团队、客户、涉众……)

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

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

软件体系结构是软件系统在其操作的某个阶段的运行时元素的抽象。一个系统可能由许多抽象层次和许多操作阶段组成，每一个都有自己的软件体系结构。

他强调“运行时元素”和“抽象层次”。

在我看来，架构只不过是一个愿景，以正确的方式收集需求并构建构建块

在设计中，构建特定的块可能有100种解决方案，但为了满足具体的要求，我们需要选择正确的方法，所以选择正确的方法或算法不是设计吗

架构是“很难改变的设计决策。”

在使用TDD之后，这实际上意味着你的设计一直在变化，我经常发现自己在这个问题上挣扎。上面的定义是从Martin Fowler的企业应用程序体系结构模式中提取的

这意味着架构依赖于你的系统的语言、框架和领域。如果你能在5分钟内从Java类中提取出一个接口，这就不再是架构决策了。

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

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

所以，我的建议是:

• 创建一个单独的设计文档。
• 按照你想要的方式命名这个设计文档，或者最好是按照读者更习惯的方式。例如:“软件体系结构”，“软件设计规范”。
• 将此文档分解为视图，并记住，您可以创建一个视图作为另一个视图的细化。
• 通过添加交叉引用或超链接，使文档中的视图可导航
• 然后，您将拥有更高级别的视图，显示广泛但肤浅的设计概述，以及更接近实现的视图，显示狭窄但更深入的设计细节。
• 你可能想看一个多视图体系结构文档(在这里)的例子。

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

体系结构更像是集成系统的各种功能，以实现系统的一个整体目标，而设计则解决每个功能需求。

例如，以MVVM为例，这是一种体系结构模式。对于通知功能，MVVM使用观察者模式，这又是一种设计模式，

设计:了解模块，模块之间的关系，每个模块的功能，类及其成员函数，每个模块相互通信的接口。

架构是软件系统的整个结构。所有模块、类和组件执行不同的任务，并将给出唯一的结果。

例如:有一个有5个房间的房子。还有附属浴室。厨房也在家里。所以家里有不同的东西这些东西之间有不同的关系。所以这一切都是关于一个家的“设计”。

而当你从房子外面看的时候，你看到的整个结构都是关于建筑的。

ARCHITECTURE:-架构在建筑的各个阶段创建规划布局

设计人员:-设计人员是一种满足建筑设计的所有基本要求的活动，包括功能、美学和设计。外观布局。

这个问题没有明确的答案，因为“软件架构”和“软件设计”有相当多的定义，而且都没有一个规范的定义。

一个很好的思考方法是Len Bass, Paul Clements和Rick Kazman的声明，“所有的架构都是设计，但并不是所有的设计都是架构”[软件架构实践]。我不确定我是否完全同意这一点(因为架构可以包括其他活动)，但它抓住了架构是处理设计的关键子集的设计活动的本质。

我稍微轻率的定义(在SEI定义页中找到)是，它是一组决策，如果做出错误的决定，将导致项目被取消。

几年前，Amnon Eden和Rick Kazman在一篇题为“架构，设计，实现”的研究论文中做了一个有用的尝试，将架构，设计和实现分离为概念，可以在这里找到:http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf。他们的语言非常抽象，但简单地说，体系结构是可以在许多上下文中使用的设计，意味着要应用于整个系统，设计是(呃)可以在许多上下文中使用的设计，但应用于系统的特定部分，而实现是特定于某个上下文中的设计，并应用于该上下文中。

因此，架构决策可能是通过消息传递而不是RPC来集成系统(因此，这是一个可以应用于许多地方的通用原则，并打算应用于整个系统)，设计决策可能是在系统的输入请求处理模块中使用主/从线程结构(一个可以在任何地方使用的通用原则，但在这种情况下，只在一个模块中使用)，最后，实现决策可能是将安全责任从Request Router转移到Request Manager模块中的Request Handler(该决策只与该上下文中相关，在该上下文中使用)。

我希望这能有所帮助!

建筑和设计密切相关;它们之间的主要区别在于我们面对的方向。 建筑面向战略、结构和目的，面向抽象。 设计面向实现，面向实践，面向具体。< p>

正如其他人指出的那样，规划软件的架构实际上是做出对软件开发或执行生命周期有整体影响的主要设计决策;所以简单地说，建筑只是高层次的设计。

即使架构决策不影响所有组件(因此是局部的)，它仍然必须是全局相关的，即它以某种方式影响整个系统;否则只是一个本地设计决策。

不过，我想指出的是，与架构相关的一个更相关的问题可能是Hennessy &帕特森计算机体系结构。基于此，我们可以将体系结构视为系统的数据模型(输入/输出，状态)抽象，而将组织视为实现(软件开发)过程中所采取的典型设计决策。

1. 架构是指计算机或基于计算机的系统的概念结构和逻辑组织。

   设计是指在一个系统或物体被制造出来之前，为显示其外观、功能或工作方式而设计的计划或图纸。

2. 如果你正在“架构”一个组件，你正在定义它在更大的系统中的行为。

   如果你在“设计”同一个组件，你就是在定义它的内部行为。

所有的建筑都是设计，但并非所有的设计都是建筑。

What部分是设计，How部分是具体实现，What和How部分的交集是架构。

区分建筑和设计的形象:

还有一些设计决策，在架构上并不重要，也就是说不属于设计的架构分支。例如，某些组件的内部设计决策，如算法的选择，数据结构的选择等。

任何在组件边界之外不可见的设计决策都是组件的内部设计，并且是非架构性的。这些是系统架构师留给模块设计人员或实现团队的设计决策，只要他们的设计不打破系统级架构施加的架构限制。

给出很好的类比的链接