有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
软件设计有更长的历史，而软件架构这个术语只有20年的历史。因此，它正在经历成长的烦恼。
学术界倾向于将架构视为更大的软件设计领域的一部分。尽管越来越多的人认识到Arch是一个独立的领域。
实践者倾向于将Arch视为高级设计决策，具有战略性，并且在项目中撤销可能代价高昂。
Arch和设计之间的确切界限取决于软件领域。例如，在Web应用领域，分层架构是目前最受欢迎的(业务逻辑层，数据访问层等)。Arch的低层部分被认为是设计(类图，方法签名等)。在嵌入式系统，操作系统，编译器等领域，这将是不同的定义。
其他回答
Cliff Notes版本:
设计:根据所需产品的规格实现解决方案。
架构:支持设计的基础/工具/基础设施/组件。
这是一个相当宽泛的问题，会引起很多人的回应。
当您需要将较高体系结构级别识别的业务和功能投射到应用程序中时，软件体系结构最好用于系统级。
例如，你的业务是关于交易员的“盈亏”，你的主要功能涉及“投资组合评估”和“风险计算”。
但是当软件架构师详细描述他的解决方案时，他会意识到:
“投资组合评估”不能只是一个应用程序。它需要在可管理的项目中进行细化，例如:
GUI 发射器 调度程序 .．.
(因为涉及的操作太大了，需要在几台计算机之间进行拆分，同时仍然可以通过一个通用的GUI随时监控)
软件设计将检查不同的应用程序，它们的技术关系和内部子组件。 它将产生最后一个体系结构层(“技术体系结构”)工作所需的规范(根据技术框架或横向组件)，以及项目团队(更面向业务功能的实现)开始各自的项目所需的规范。
设计:了解模块，模块之间的关系，每个模块的功能，类及其成员函数，每个模块之间通信的接口。
体系结构:体系结构是软件系统的整个结构。所有模块、类和组件执行不同的任务，并将给出唯一的结果。
例如:有一个有5个房间的房子。还有附属浴室。厨房也在家里。所以家里有不同的东西这些东西之间有不同的关系。所以这一切都是关于一个家的“设计”。
而当你从房子外面看的时候，你看到的整个结构都是关于建筑的。
我像Patrick Karcher一样看待建筑——从大局出发。例如，您可以为建筑物提供架构，查看其结构支撑、窗户、入口和出口、排水等。但你并没有“设计”楼层布局、隔间位置等。
所以当你设计了大楼的时候，你并没有设计每个办公室的布局。 我认为这同样适用于软件。
你可以把设计布局看作是“设计布局”……
架构是“难以改变的设计决策”。
在使用TDD之后，这实际上意味着你的设计一直在变化，我经常发现自己在这个问题上挣扎。上面的定义摘自Martin Fowler的《企业应用程序体系结构模式》
这意味着架构依赖于你的系统的语言、框架和领域。如果你能在5分钟内从Java类中提取出一个接口，这就不再是架构决策了。
