有人能解释一下软件设计和软件架构的区别吗?

更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。

我目前的理解是:

设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信),要使用什么语言,模式……?

如果我说错了,请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章,但我不确定我是否理解正确。


当前回答

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

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

所以,我的建议是:

create a single design document. name this design document the way you want or, better, the way the readers are more accustomed to. Examples: "Software Architecture", "Software Design Specification". break this document into views and keep in mind you can create a view as a refinement of another view. make the views in the document navigable by adding cross-references or hyperlinks then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details. you may want to take a look at an example of multi-view architecture document (here).

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

其他回答

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

(来自维基百科,http://en.wikipedia.org/wiki/Software_architecture)

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

(来自维基百科,http://en.wikipedia.org/wiki/Software_design)

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

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

架构: 结构设计是在更高的抽象层次上进行的工作,它将技术上重要的需求实现到系统中。该体系结构为进一步的设计奠定了基础。

设计: 通过在每个抽象层的迭代过程来填充架构所没有的内容的艺术。

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

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

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

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

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

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

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