我认为当我们讨论设计与架构时，我们应该使用下面的规则来确定:如果您创建的软件图的元素可以一一映射到编程语言的语法结构，那么就是设计，如果不是架构。

So, for example, if you are seeing a class diagram or a sequence diagram, you are able to map a class and their relationships to an Object Oriented Programming language using the Class syntactical construction. This is clearly Design. In addition, this might bring to the table that this discussion has a relation with the programming language you will use to implement a software system. If you use Java, the previous example applies, as Java is an Object Oriented Programming Language. If you come up with a diagram that shows packages and its dependencies, that is Design too. You can map the element (a package in this case) to a Java syntactical construction.

Now, suppose your Java application is divided in modules, and each module is a set of packages (represented as a jar file deployment unit), and you are presented with a diagram containing modules and its dependencies, then, that is Architecture. There isn’t a way in Java (at least not until Java 7) to map a module (a set of packages) to a syntactical construction. You might also notice that this diagram represents a step higher in the level of abstraction of your software model. Any diagram above (coarse grained than) a package diagram, represents an Architectural view when developing in the Java programming language. On the other hand, if you are developing in Modula-2, then, a module diagram represents a Design.

(摘自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)

当我寻找建筑和设计之间的简单区别时，我发现了这一点; 你对这种看待他们的方式有什么看法?

架构是我们正在建造的“什么”; 设计是我们“如何”建造;

如果有人建造了一艘船，那么发动机、船体、电路等将是他的“建筑元素”。对他来说，发动机制造将是“设计工作”。

如果他将引擎的构建委托给另一个团队，他们将创建一个“引擎架构”……

这取决于抽象和细节的程度。一个人的建筑可能是另一个人的设计!

在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.

我喜欢Roy Thomas Fielding在他的论文中对什么是软件架构的定义和解释: 架构风格与基于网络的软件架构设计

软件体系结构是软件系统在其操作的某个阶段的运行时元素的抽象。一个系统可能由许多抽象层次和许多操作阶段组成，每一个都有自己的软件体系结构。

他强调“运行时元素”和“抽象层次”。

体系结构是用于构建系统的设计模式的最终集合。

我猜设计是用来把所有这些放在一起的创造力?