软件设计与软件架构
有人可以解释一下软件设计和软件架构之间的区别吗？
进一步来说; 如果你告诉某人向你展示“设计”——你希望他们展示什么？ “建筑”也是如此。
我目前的理解是：
- 设计：针对特定模块/系统的一部分的UML图/流程图/简单线框图（用于UI）
- 架构：组件图（显示系统的不同模块如何相互通信以及与其他系统通信），使用什么语言、模式......？
如我错了请纠正我。 我已经提到维基百科有关于 http://en.wikipedia.org/wiki/Software_design 的文章http://en.wikipedia.org/wiki/Software_architecture，但我不确定是否我已经正确理解了它们。
Could someone explain the difference between Software Design and Software Architecture?
More specifically; if you tell someone to present you the 'design' - what would you expect them to present? Same goes for 'architecture'.
My current understanding is:
- Design: UML diagram/flow chart/simple wireframes (for UI) for a specific module/part of the system
- Architecture: component diagram (showing how the different modules of the system communicates with each other and other systems), what language is to be used, patterns...?
Correct me if I'm wrong. I have referred Wikipedia has articles on http://en.wikipedia.org/wiki/Software_design and http://en.wikipedia.org/wiki/Software_architecture, but I'm not sure if I have understood them correctly.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（30）
你是对的。 系统的架构是它的“骨架”。 它是系统的最高抽象级别。 存在什么样的数据存储，模块之间如何交互，有哪些恢复系统。 就像设计模式一样，也有架构模式：MVC、3 层分层设计等。
软件设计是设计各个模块/组件。 模块 x 的职责、功能是什么？ Y级的？ 它能做什么，不能做什么？ 可以使用哪些设计模式？
所以简而言之，软件架构更多的是整个系统的设计，而软件设计则强调模块/组件/类层面。
You're right yes. The architecture of a system is its 'skeleton'. It's the highest level of abstraction of a system. What kind of data storage is present, how do modules interact with each other, what recovery systems are in place. Just like design patterns, there are architectural patterns: MVC, 3-tier layered design, etc.
Software design is about designing the individual modules / components. What are the responsibilities, functions, of module x? Of class Y? What can it do, and what not? What design patterns can be used?
So in short, Software architecture is more about the design of the entire system, while software design emphasizes on module / component / class level.
在SDLC（软件开发生命周期）的一些描述中，它们是可以互换的，但共识是它们是不同的。 它们同时处于：不同的 (1) 阶段、(2) 责任范围以及 (3) 决策级别 。
这两个阶段似乎会因为不同的原因混合在一起。
即使各个阶段或责任领域混合在一起并且发生在各个地方，了解正在发生什么级别的决策总是有好处的。 （我们可以永远继续下去。我试图将其保留为摘要。）我会以以下内容结束：即使您的项目似乎没有正式的架构或设计阶段/AOR/文档，但无论是否有人，它都会发生有意识地做或不做。 如果没有人决定做架构，那么默认的架构可能会很糟糕。 设计也是如此。 如果没有正式的阶段来代表这些概念，它们几乎会更加重要。
In some descriptions of the SDLC (Software Development Life Cycle) they are interchangeable, but the consesus is that they are distinct. They are at the same time: different (1) stages, (2) areas of responsibility, and (3) levels of decision-making.
These two stages will seem to blend together for different reasons.
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.
架构是战略性的，而设计是战术性的。
架构包括框架、工具、编程范式、基于组件的软件工程标准、高级原则。
而设计是涉及局部约束的活动，例如设计模式、编程习惯和重构。
Architecture is strategic, while Design is tactical.
Architecture comprises the frameworks, tools, programming paradigms, component-based software engineering standards, high-level principles..
While design is an activity concerned with local constraints, such as design patterns, programming idioms, and refactorings.
我发现这一点是因为我自己正在寻找架构和设计之间的简单区别；
您如何看待这种看待它们的方式：
I found this as I was looking for simple distinction between architecture and design myself;
What do you think of this way of looking at them:
架构是指计算机或基于计算机的系统的概念结构和逻辑组织。
设计是指在系统或物体制作之前为显示外观、功能或工作原理而制作的计划或绘图。
如果您正在“构建”一个组件，您就是在定义它在更大系统中的行为方式。
如果您“设计”相同的组件，您就是在定义它的内部行为方式。
What部分是设计，How是具体实现，What和How的交集是架构。区分架构和设计的图像：
还有一些设计决策，但不是具有建筑意义，即不属于设计的建筑分支。 例如，某些组件的内部设计决策，例如算法的选择、数据结构的选择等。
任何在组件边界之外不可见的设计决策都是组件的内部设计，并且是非体系结构的。 这些是系统架构师将由模块设计者或实施团队自行决定的设计决策，只要他们的设计不打破系统级架构所施加的架构约束即可。
该链接提供了很好的类比
Architecture means the conceptual structure and logical organization of a computer or computer-based system.
Design means a plan or drawing produced to show the look and function or workings of a system or an object before it is made.
If you are “architecting” a component, you are defining how it behaves in the larger system.
If you are “designing” the same component, you are defining how it behaves internally.
Whatpart is the Design, theHowis the concrete implementation and the intersection ofWhatandHowis Architecture.Image for differentiating Architecture and Design:
There are also design decisions, that are not architecturally significant, i.e. does not belongs to the architecture branch of design. For example, some component’s internal design decisions, like- choice of algorithm, selection of data structure etc.
Any design decision, which isn’t visible outside of its component boundary is a component’s internal design and is non-architectural. These are the design decisions a system architect would leave on module designer’s discretion or the implementation team as long as their design don’t break the architectural constraints imposed by the system level architecture.
The link that gives good analogy
用我自己的话来说，我想说你是对的；
架构是将系统需求分配给系统元素。 关于架构的四个陈述：
当系统的复杂性被细分时，架构是基本的工程步骤。
示例：想象一下您的房子，您的厨房不需要建筑师（仅涉及一个元素），但整个建筑需要一些交互定义，例如门和屋顶。
设计是功能（建议的）实现的信息表示。 其目的是征求反馈并与利益相关者进行讨论。 这可能是很好的做法，但不是必要的工程步骤。
如果能在安装厨房之前看到厨房设计就好了，但这对于烹饪要求来说并不是必需的：
如果我考虑一下，你可以说：
I'd say you are right, in my own words;
Architecture is the allocation of system requirements to system elements. Four statements about an architecture:
Architecture is an essential engineering step when a complexity of the system is subdivided.
Example: Think about your house, you don't need an architect for your kitchen (only one element involved) but the complete building needs some interaction definitions, like doors, and a roof.
Design is a informative representation of the (proposed) implementation of the function. It is intended to elicit feedback and to discuss with stakeholders. It might be good practice but is not an essential engineering step.
It would be nice to see the kitchen design see before the kitchen is installed but it is not essential for the cooking requirement:
If I think about it you can state:
我的提醒：
My reminder:
我认为我们应该使用以下规则来确定何时讨论设计与架构：如果您创建的软件图片的元素可以一对一映射到编程语言语法结构，那么就是设计，如果不是，就是架构。
因此，例如，如果您看到类图或序列图，则可以使用类语法结构将类及其关系映射到面向对象编程语言。 这显然是设计。 此外，这可能表明该讨论与您将用于实现软件系统的编程语言有关。 如果您使用 Java，则前面的示例适用，因为 Java 是一种面向对象的编程语言。 如果您拿出一个显示包及其依赖项的图表，那么这也是设计。 您可以将元素（在本例中为包）映射到 Java 语法结构。
现在，假设您的Java应用程序被划分为模块，每个模块是一组包（表示为jar文件部署单元），并且向您呈现一个包含模块及其依赖项的图表，那么，这就是架构。 Java 中没有一种方法（至少在 Java 7 之前）可以将模块（一组包）映射到语法结构。 您可能还会注意到，该图代表了软件模型的抽象级别更高的一步。 包图上方的任何图（比包图更粗粒度）都代表使用 Java 编程语言进行开发时的体系结构视图。 另一方面，如果您在 Modula-2 中进行开发，那么模块图代表一个设计。
（来自 http://www.copypasteisforword.com/notes/software-architecture-vs- 的片段软件设计）
I think we should use the following rule to determine when we talk about Design vs Architecture: If the elements of a software picture you created can be mapped one to one to a programming language syntactical construction, then is Design, if not is Architecture.
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.
(A fragment from http://www.copypasteisforword.com/notes/software-architecture-vs-software-design)
就我个人而言，我喜欢这一点：
“设计师关心的是当用户按下一个按钮时会发生什么，而架构师关心的是当一万个用户按下一个按钮时会发生什么。”
SCEA for Java™ EE 学习指南，作者：Mark Cade 和 Humphrey Sheil
Personally, I like this one:
"The designer is concerned with what happens when a user presses a button, and the architect is concerned with what happens when ten thousand users press a button."
SCEA for Java™ EE Study Guide by Mark Cade and Humphrey Sheil
我同意许多解释； 本质上，我们正在认识到软件系统的架构设计和详细设计之间的区别。
虽然设计者的目标是使规格尽可能精确和具体，因为这是开发所必需的； 架构师的主要目标是按照详细设计开始时的要求来指定系统的结构和全局行为。
一个好的架构师将防止超规范 - 架构不能过度指定，而必须足够，仅针对那些需要处理的风险最高的方面而建立（架构）决策，并有效地提供一个框架（“共性”），在该框架中可以进行详细设计，即局部功能的可变性。
事实上，架构过程或生命周期只是遵循这个主题 - 足够的抽象级别来概述（架构上）重要业务需求的结构，并将更多细节留给设计阶段以获得更具体的可交付成果。
I agree with many of the explanations; essentially we are recognizing the distinction between the architectural design and the detailed design of the software systems.
While the goal of the designer is to be as precise and concrete in the specifications as it will be necessary for the development; the architect essentially aims at specifying the structure and global behavior of the system just as much as required for the detailed design to begin with.
A good architect will prevent hyper-specifications - the architecture must not be overly specified but just enough, the (architectural) decisions established only for the aspects that present costliest risks to handle, and effectively provide a framework ("commonality") within which the detailed design can be worked upon i.e. variability for local functionality.
Indeed, the architecture process or life-cycle just follows this theme - adequate level of abstraction to outline the structure for the (architecturally) significant business requirements, and leave more details to the design phase for more concrete deliverables.
建筑是设计，但并非所有设计都是建筑。因此，严格来说，尝试区分建筑设计和非建筑设计会更有意义。 又有什么区别呢？ 这取决于！ 每个软件架构师可能有不同的答案（ymmv！）。 我们开发启发式方法来得出答案，例如“类图是架构，序列图是设计”。 有关详细信息，请参阅 DSA 书籍。
人们通常说架构比设计处于更高的抽象级别，或者架构是逻辑的，设计是物理的。 但这种观念虽然被普遍接受，但在实践中却毫无用处。 您如何在高抽象和低抽象、逻辑抽象和物理抽象之间划清界限？ 这取决于！
所以，我的建议是：
话虽如此......我们需要问的一个更相关的问题是：多少设计就足够了？也就是说，我什么时候应该停止描述设计（用图表或散文）并应该继续前进编码？
Architecture is design, but not all design is architectural. Therefore, strictly speaking, it would make more sense to try to differentiate between architectural design and non-architectural design. And what is the difference? It depends! Each software architect may have a different answer (ymmv!). We develop our heuristics to come up with an answer, such as 'class diagrams are architecture and sequence diagrams are design'. See DSA book for more.
It's common to say that architecture is at a higher abstraction level than design, or architecture is logical and design is physical. But this notion, albeit commonly accepted, is in practice useless. Where do you draw the line between high or low abstraction, between logical and physical? It depends!
So, my suggestion is:
Having said all that... a more relevant question we need to ask is: how much design is enough? That is, when should I stop describing the design (in diagrams or prose) and should move on to coding?
是的，这对我来说听起来不错。 设计是你要做的事情，而架构是将设计的各个部分连接在一起的方式。 它可能与语言无关，但通常会指定要使用的技术，即 LAMP 与 Windows、Web 服务与 RPC。
Yep that sounds right to me. The design is what you're going to do, and architecture is the way in which the bits and pieces of the design will be joined together. It could be language agnostic, but would normally specify the technologies to be used ie LAMP v Windows, Web Service v RPC.
程序或计算系统的软件架构是系统的一个或多个结构，它包括软件组件、这些组件的外部可见属性以及它们之间的关系。
（来自维基百科，http://en.wikipedia.org/wiki/Software_architecture）
软件设计是解决问题和规划软件解决方案的过程。 在确定软件的用途和规格后，软件开发人员将设计或聘请设计人员制定解决方案的计划。 它包括低级组件和算法实现问题以及架构视图。
（来自维基百科，http://en.wikipedia.org/wiki/Software_design）
无法我自己也没有说得更好:)
The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them.
(from Wikipedia, http://en.wikipedia.org/wiki/Software_architecture)
Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.
(from Wikipedia, http://en.wikipedia.org/wiki/Software_design)
Couldn't have said it better myself :)
我像帕特里克·凯彻一样看待建筑——大局观。 例如，您可以为建筑物提供架构，查看其结构支撑、窗户、入口和出口、排水等。但是您还没有“设计”楼层布局、隔间位置等。
因此，虽然您已经设计了你还没有设计大楼里每个办公室的布局。
我认为软件也是如此。
您可以将设计布局视为“构建布局”......
I view architecture as Patrick Karcher does - the big picture. For example, you can provide the architecture to a building, view its structural support, the windows, entries and exits, water drainage, etc. But you have not "designed" the floor layout's, cubicle positions etc.
So while you've architected the building you have not designed the layout of each office.
I think the same holds true for software.
You could view designing the layout, as "architecting the layout" though ...
好问题......虽然它们之间的界限很难说是一条明亮的清晰界限，但恕我直言，如果您同时使用这两个术语，那么架构包含更多关于如何构建或构造某些东西的技术或结构决策，尤其是那些困难的决策（或更难）一旦实现就改变，而设计包含那些以后很容易改变的决定（比如方法名称、类<->文件组织结构、设计模式、是否使用单例或静态类来解决某些问题）具体问题等）和/或影响系统或应用程序的外观或美观方面的问题（人机界面、易用性、外观和感觉等）
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.)
软件架构“关注的是计算的算法和数据结构之外的问题。
架构具体来说不是关于……实现的细节（例如，算法和数据结构）。架构设计涉及比 OOD（面向对象设计）通常提供的更丰富的抽象集合。
设计关注设计元素的模块化和详细接口、算法和过程以及支持架构和满足需求所需的数据类型。
“建筑”经常被用作“设计”的同义词（有时前面带有形容词“高级”）。 许多人将“架构模式”一词用作“设计模式”的同义词。
查看此链接。
定义术语架构、设计和实现
Software architecture is“concerned with issues...beyond the algorithms and data structures of the computation.
Architecture is specifically not about…details of implementations (e.g., algorithms and data structures.) Architectural design involves a richer collection of abstractions than is typically provided by OOD” (object-oriented design).
Design is concerned with the modularization and detailed interfaces of the design elements, their algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.
“architecture” is often used as a mere synonym for “design” (sometimes preceded with the adjective “high-level”). And many people use the term “architectural patterns” as a synonym for “design patterns.”
Check out this link.
Defining the Terms Architecture, Design, and Implementation
架构：
结构设计工作在更高的抽象层次上，实现了系统的技术上的重要要求。 该架构为进一步的设计奠定了基础。
设计：
通过在每个抽象层的迭代过程来填充架构未完成的内容的艺术。
Architecture:
Structural design work at higher levels of abstraction which realize technically significant requirements into the system. The architecture lays down foundation for further design.
Design:
The art of filling in what the architecture does not through an iterative process at each layer of abstraction.
我真的很喜欢这篇论文，它提供了将架构与设计分离的经验法则：
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
这称为内涵/局部性假设。 关于非本地和内涵的软件性质的声明是架构性的。 局部和内涵的陈述是设计。
I really liked this paper for a rule of thumb on separating architecture from design:
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
It's called the Intension/Locality hypothesis. Statements on the nature of the software that are non-local and intensional are architectural. Statements that are local and intensional are design.
...很久以前，在一个遥远的地方，哲学家们担心一与多之间的区别。 建筑是关于关系的，这需要很多。 架构有组件。 设计是关于内容的，这就需要内容。 设计具有属性、品质、特征。 我们通常认为设计属于建筑范畴。 二元论思维将多数视为原始的。 但建筑也在设计之中。 这就是我们选择如何看待摆在我们面前的事物——一个或多个。
...long time ago in a faraway place philosophers worried about the distinction between the one and the many. Architecture is about relationship, which requires the many. Architecture has components. Design is about content, which requires the one. Design has properties, qualities, characteristics. We typically think that design is within architecture. Dualistic thinking gives the many as primordial. But architecture is also within design. It's all how we choose to view what is before us - the one or the many.
相当主观，但我的看法是：
架构
系统的总体设计包括与其他系统的交互、硬件要求、总体组件设计和数据流。
设计
整个系统中组件的组织和流程。 这还包括该组件用于与其他组件交互的 API。
Pretty subjective but my take:
Architecture
The overall design of the system including interactions with other systems, hardware requirement, overall component design, and data flow.
Design
The organization and flow of a component in the overall system. This would also include the component's API for interaction with other components.
当您需要将更高架构级别识别的业务和功能项目到应用程序中时，软件架构最好在系统级别使用。
例如，您的业务是关于交易者的“盈亏”，您的主要功能涉及“投资组合评估”和“风险计算”。
但是，当软件架构师详细描述他的解决方案时，他会意识到：
“组合评估”可以不仅仅是一个应用程序。 它需要在可管理的项目中进行完善，例如：
（因为涉及的操作非常庞大，因此需要在多台计算机之间进行拆分，同时仍然通过通用 GUI 始终进行监控）
软件设计将检查不同的应用程序、它们的技术关系及其内部子组件。
它将生成最后一个架构层（“技术架构”）所需的规范工作（在技术框架或横向组件方面），并让项目团队（更注重业务功能的实现）开始各自的项目。
Software architecture is best used at the system level, when you need to project business and functions identify by higher architecture levels into applications.
For instance, your business is about "Profit and Loss" for traders, and your main functions involved "portfolio evaluation" and "risk computation".
But when a Software Architect will details his solution, he will realize that:
"portfolio evaluation" can not be just one application. It needs to be refined in manageable projects like:
(because the operations involved are so huge they need to be split between several computers, while still being monitored at all times through a common GUI)
a Software design will examine the different applications, their technical relationship and their internal sub-components.
It will produce the specifications needed for the last Architecture layer (the "Technical Architecture") to work on (in term of technical framework or transversal components), and for the project teams (more oriented on the implementation of the business functions) to begin their respective projects.
如果有人建造一艘船，那么发动机、船体、电路等将是他的“建筑元素”。 对他来说，发动机制造将是“设计工作”。
如果他随后将引擎的构建委托给另一个团队，他们将创建一个“引擎架构”......
所以 - 这取决于抽象或细节的级别。 一个人的建筑可能是另一个人的设计！
if somebody constructs a ship, then engine, hull, electric-circuits etc. will be his "architectural elements". For him, engine-construction will be "design work".
If he then delegates the construction of the engine to another team, they will create an "engine architecture"...
So - it depends on the level of abstraction or detail. One persons' architecture might be anothers' design!
架构是“难以改变的设计决策。”
在使用TDD（这实际上意味着你的设计一直在变化）之后，我经常发现自己在这个问题上挣扎。 上面的定义摘自 Martin Fowler 的企业应用程序架构模式
这意味着架构取决于系统的语言、框架和领域。 如果您可以在 5 分钟内从 Java 类中提取一个接口，那么它就不再是架构决策了。
Architecture are "the design decisions that are hard to change."
After working with TDD, which practically means that your design changes all the time, I often found myself struggling with this question. The definition above is extracted from Patterns of Enterprise Application Architecture, By Martin Fowler
It means that the architecture depends on the Language, Framework and the Domain of your system. If your can just extract an interface from your Java Class in 5 minutes it is no longer and architecture decision.
Cliff Notes 版本：
设计：根据所需产品的规格实施解决方案。
架构：支持您的设计的基础/工具/基础设施/组件。
这是一个相当广泛的问题，会引起很多回应。
Cliff Notes version:
Design: Implementing a solution based on the specifications of the desired product.
Architecture: The foundation/tools/infrastructure/components that support your design.
This is a pretty broad question that will invoke a lot of responses.
架构是构建系统的设计模式的集合。
我想设计就是用来将这一切组合在一起的创造力？
Architecture is the resulting collection of design patterns to build a system.
I guess Design is the creativity used to put all this together?
软件设计有着悠久的历史，而软件架构这个术语只有 20 年的历史。 因此，它现在正在经历成长的阵痛。
学者们倾向于将架构视为更大的软件设计领域的一部分。 尽管人们越来越认识到 Arch 是一个独立的领域。
从业者倾向于将 Arch 视为具有战略性的高层设计决策，并且在项目中撤销的成本可能会很高。
Arch 和设计之间的确切界限取决于软件领域。 例如，在Web应用程序领域，分层架构目前最流行（业务逻辑层、数据访问层等）。该架构的较低层部分被认为是设计（类图、方法签名等）。 ）这在嵌入式系统、操作系统、编译器等领域会有不同的定义。
Software design has a longer history while the term software architecture is barely 20 years old. Hence, it is going through growing pains right now.
Academics tend to see Architecture as part of the larger field of software design. Although there is growing recognition that Arch is a field within it's own.
Practitioners tend to see Arch as high-level design decisions that are strategic and can be costly in a project to undo.
The exact line between Arch and design depends on the software domain. For instance, in the domain of Web Applications, the layered architecture is gaining the most popularity currently (Biz Logic Layer, Data Access Layer, etc.) The lower level parts of this Arch are considered design (class diagrams, method signatures, etc.) This would be defined differently in the domains of embedded systems, operating systems, compilers, etc.
架构是高层、抽象和逻辑设计，而软件设计是低层、详细和物理设计。
Architecture is high level, abstract and logical design whereas software design is low level,detailed and physical design.
另请参阅：
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
Also, refer to:
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
我喜欢 Roy Thomas Fielding 在他的论文中对软件架构的定义和解释：
基于网络的软件架构的架构风格和设计
他强调“运行时元素”和“抽象级别”。
I like Roy Thomas Fielding's definition and explanation about what is software architecture in his paper:
Architectural Styles and the Design of Network-based Software Architectures
He emphasizes "run-time elements" and "levels of abstraction".
对此没有明确的答案，因为“软件架构”和“软件设计”有相当多的定义，而且都没有规范的定义。
Len Bass、Paul Clements 和 Rick Kazman 的说法是一种很好的思考方式：“所有架构都是设计，但并非所有设计都是架构”[实践中的软件架构]。 我不确定我是否完全同意这一点（因为架构可以包括其他活动），但它抓住了架构是一种处理设计的关键子集的设计活动的本质。
我的定义有点轻率（在 SEI 定义页）的特点是，如果做出错误的决定，就会导致您的项目被取消。
几年前，Amnon Eden 和 Rick Kazman 在一篇题为“架构、设计、实现”的研究论文中进行了将架构、设计和实现作为概念进行分离的有益尝试，该论文可以在此处找到：http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf。 他们的语言非常抽象，但简单地说，架构是可以在许多上下文中使用的设计，并且旨在跨系统应用，设计是（错误的）设计可以在许多上下文中使用，但应用于系统的特定部分，而实现是特定于上下文的设计并应用于该上下文。
因此，架构决策可能是通过消息传递而不是 RPC 来集成系统的决策（因此这是一个可以应用于许多地方并且旨在应用于整个系统的通用原则），设计决策可能是使用 master系统的输入请求处理模块中的 /slave 线程结构（可以在任何地方使用的一般原则，但在本例中仅在一个模块中使用），最后，实施决策可能是将安全责任从请求路由器转移出去到请求管理器模块中的请求处理程序（仅与该上下文相关的决策，在该上下文中使用）。
我希望这有帮助！
There is no definitive answer to this because "software architecture" and "software design" have quite a number of definitions and there isn't a canonical definition for either.
A good way of thinking of it is Len Bass, Paul Clements and Rick Kazman's statement that "all architecture is design but not all design is architecture" [Software Architecture in Practice]. I'm not sure I quite agree with that (because architecture can include other activities) but it captures the essence that architecture is a design activity that deals with the critical subset of design.
My slightly flippant definition (found on the SEI definitions page) is that it's the set of decisions which, if made wrongly, cause your project to get cancelled.
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).
I hope this helps!