有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
体系结构是用于构建系统的设计模式的最终集合。
我猜设计是用来把所有这些放在一起的创造力?
其他回答
体系结构确定了系统的基本组件，描述了它们的组织，以及它们与创建系统框架的关系。
设计描述了各种组件，以及应该如何在系统架构提供的框架中开发它们以提供所需的功能。
Cliff Notes版本:
设计:根据所需产品的规格实现解决方案。
架构:支持设计的基础/工具/基础设施/组件。
这是一个相当宽泛的问题，会引起很多人的回应。
在SDLC(软件开发生命周期)的一些描述中，它们是可互换的，但共识是它们是不同的。它们同时是:不同的(1)阶段，(2)责任领域，(3)决策层次。
架构是更大的图景:框架、语言、范围、目标和高级方法(Rational、瀑布式、敏捷等)的选择。 设计是更小的画面:如何组织代码的计划;系统不同部分之间的契约将会是怎样的;项目方法和目标的持续实施。规范是在这个阶段编写的。
由于不同的原因，这两个阶段似乎融合在一起。
Smaller projects often don't have enough scope to separate out planning into these to stages. A project might be a part of a larger project, and hence parts of both stages are already decided. (There are already existing databases, conventions, standards, protocols, frameworks, reusable code, etc.) Newer ways of thinking about the SDLC (see Agile methodologies) somewhat rearrange this traditional approach. Design (architecture to a lesser extent) takes place throughout the SDLC on purpose. There are often more iterations where the whole process happens over and over. Software development is complicated and difficult to plan anyway, but clients/managers/salespeople usually make it harder by changing goals and requirements mid-stream. Design and even architectural decisions must bemade later in the project whether that is the plan or not.
Even if the stages or areas of responsibility blend together and happen all over the place, it is always good to know what level of decision-making is happening. (We could go on forever with this. I'm trying to keep it a summary.) I'll end with: Even if it seems your project has no formal architectural or design stage/AOR/documentaiton, it IS happening whether anyone is consciously doing it or not. If no one decides to do architecture, then a default one happens that is probably poor. Ditto for design. These concepts are almost more important if there are no formal stages representing them.
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
架构告诉您系统是如何布局的。一个传统的体系结构模式示例是3层系统，其中系统被分解为表示层、业务层和数据层。
领域驱动的设计促进了4层架构。表示层、应用层、域层和基础结构层。存储库模式位于域层和基础结构层之间。你的领域模型不应该知道任何关于基础设施的信息，同时也应该保持纯粹并独立于基础设施。这就是为什么我们有存储库来协调这两层。
存储库模式仍然是一个模式，因为它是一个可重用的解决方案，可以处理重复出现的问题。然而，只有当我们讨论架构时，存储库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案，例如抽象工厂模式，可以应用于系统中的任何地方。
以下是可能更详细地解释体系结构的参考资料和软件体系结构的UML图列表。(我找不到用于软件设计的UML图列表)
Grady Booch
在架构模型中使用UML 2图
UML图的分类
UML图的分类
即使在发布了这个答案之后，我自己也不清楚哪个图是用于架构的，哪个图是用于设计的:)。Grady Booch在他的第58张幻灯片中指出，类、接口和协作是设计视图的一部分，而这个设计视图是架构视图的一部分!!
