设计:了解模块，模块之间的关系，每个模块的功能，类及其成员函数，每个模块之间通信的接口。

体系结构:体系结构是软件系统的整个结构。所有模块、类和组件执行不同的任务，并将给出唯一的结果。

例如:有一个有5个房间的房子。还有附属浴室。厨房也在家里。所以家里有不同的东西这些东西之间有不同的关系。所以这一切都是关于一个家的“设计”。

而当你从房子外面看的时候，你看到的整个结构都是关于建筑的。

体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。 设计是指在一个系统或物体被制造出来之前，为显示其外观、功能或工作方式而设计的计划或图纸。 如果您正在“架构”一个组件，那么您正在定义它在更大的系统中的行为。 如果你在“设计”同一个组件，你就是在定义它的内部行为。

所有的建筑都是设计，但并非所有的设计都是建筑。

什么部分是设计，如何具体实现，以及什么和如何是架构的交集。

区分建筑和设计的形象:

还有一些设计决策，在架构上并不重要，也就是说不属于设计的架构分支。例如，某些组件的内部设计决策，如算法的选择，数据结构的选择等。

任何在组件边界之外不可见的设计决策都是组件的内部设计，并且是非架构性的。这些是系统架构师留给模块设计人员或实现团队的设计决策，只要他们的设计不打破系统级架构施加的架构限制。

这个链接提供了一个很好的类比

架构设计的基本原理来自于各种因素，其中最重要的是非功能性需求，比如可伸缩性，当然最重要的是经验。没有了理论基础，你就只剩下平淡的模式，或者怎么做。无论是在更高的层次上还是在类的层次上，它仍然是设计。

或者换句话说

架构是元设计，即设计设计。您有一些已知的模式适合某个解决方案空间，您会选择哪个，为什么?架构是当你回答“是哪个”和“为什么”时(“如何”已经在设计中给出了)。它当然不依赖于抽象级别，例如实现分布式会话不是一个类级别的任务，但是对于给定的体系结构有一些设计可供选择。

同样，体系结构也反映在类级设计中。在可伸缩的体系结构下，如果不考虑可伸缩性因素，类设计通常是不同的。为什么你必须有一个方法“BeginAsyncUpload”而不是“Upload”是一个架构决策。

有趣的是，当我们将注意力转移到更高层次的系统元素时，“哪个和为什么”问题变得更加重要，而“如何”变得不那么相关。从另一个方向来看，“如何”部分变得更加重要，这也是因为重复使用使得它变得很明显，例如，在抽象工厂和原型之间进行选择。

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

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

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

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

这个问题没有明确的答案，因为“软件架构”和“软件设计”有相当多的定义，而且都没有一个规范的定义。

一个很好的思考方法是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).

我希望这能有所帮助!