有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
这个问题没有明确的答案，因为“软件架构”和“软件设计”有相当多的定义，而且都没有一个规范的定义。
一个很好的思考方法是Len Bass, Paul Clements和Rick Kazman的声明，“所有的架构都是设计，但并不是所有的设计都是架构”[软件架构实践]。我不确定我是否完全同意这一点(因为架构可以包括其他活动)，但它抓住了架构是处理设计的关键子集的设计活动的本质。
我的稍微轻率的定义(在SEI定义页面上找到)是，它是一组决策，如果做出错误的决定，将导致项目被取消。
A useful attempt at separating architecture, design and implementation as concepts was done by Amnon Eden and Rick Kazman some years ago in a research paper entitled "Architecture, Design, Implementation" which can be found here: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf. Their language is quite abstract but simplistically they say that architecture is design that can be used in many contexts and is meant to be applied across the system, design is (err) design that can be used in many contexts but is applied in a specific part of the system, and implementation is design specific to a context and applied in that context.
So an architectural decision could be a decision to integrate the system via messaging rather than RPC (so it's a general principle that could be applied in many places and is intended to apply to the whole system), a design decision might be to use a master/slave thread structure in the input request handling module of the system (a general principle that could be used anywhere but in this case is just used in one module) and finally, an implementation decision might be to move responsibilities for security from the Request Router to the Request Handler in the Request Manager module (a decision relevant only to that context, used in that context).
我希望这能有所帮助!
其他回答
Cliff Notes版本:
设计:根据所需产品的规格实现解决方案。
架构:支持设计的基础/工具/基础设施/组件。
这是一个相当宽泛的问题，会引起很多人的回应。
就我个人而言，我喜欢这个:
“设计师关心的是当一个用户按下一个按钮时会发生什么，而架构师关心的是当一万个用户按下一个按钮时会发生什么。”
由Mark Cade和Humphrey Sheil编写的Java™EE学习指南
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
架构告诉您系统是如何布局的。一个传统的体系结构模式示例是3层系统，其中系统被分解为表示层、业务层和数据层。
领域驱动的设计促进了4层架构。表示层、应用层、域层和基础结构层。存储库模式位于域层和基础结构层之间。你的领域模型不应该知道任何关于基础设施的信息，同时也应该保持纯粹并独立于基础设施。这就是为什么我们有存储库来协调这两层。
存储库模式仍然是一个模式，因为它是一个可重用的解决方案，可以处理重复出现的问题。然而，只有当我们讨论架构时，存储库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案，例如抽象工厂模式，可以应用于系统中的任何地方。
是的，对我来说听起来不错。设计是你要做的事情，而架构是将设计的各个部分连接在一起的方式。它可以是语言不可知的，但通常会指定要使用的技术，例如LAMP vs Windows, Web服务vs RPC。
架构是“难以改变的设计决策”。
在使用TDD之后，这实际上意味着你的设计一直在变化，我经常发现自己在这个问题上挣扎。上面的定义摘自Martin Fowler的《企业应用程序体系结构模式》
这意味着架构依赖于你的系统的语言、框架和领域。如果你能在5分钟内从Java类中提取出一个接口，这就不再是架构决策了。
