有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的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://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
架构告诉您系统是如何布局的。一个传统的体系结构模式示例是3层系统,其中系统被分解为表示层、业务层和数据层。
领域驱动的设计促进了4层架构。表示层、应用层、域层和基础结构层。存储库模式位于域层和基础结构层之间。你的领域模型不应该知道任何关于基础设施的信息,同时也应该保持纯粹并独立于基础设施。这就是为什么我们有存储库来协调这两层。
存储库模式仍然是一个模式,因为它是一个可重用的解决方案,可以处理重复出现的问题。然而,只有当我们讨论架构时,存储库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案,例如抽象工厂模式,可以应用于系统中的任何地方。
Good question... Although the line between them is hardly a bright sharp line, imho, if you are using both terms, then Architecture encompasses more technical or structural decisions about how to build or construct something, especially those decisions that will be hard (or harder) to change once implemeneted, whereas Design encompasses those decisions that either are easy to change later (like method names, class <-> file organizational structure, design patterns, whether to use a singleton or a static class to solve some specific problem, etc. ) and/or those that effect the appearance or esthetic aspects of a system or application (Human Interface, ease of use, look and feel, etc.)