架构:架构在建筑的各个阶段创建规划布局 按规格。

设计人员:-设计人员的工作是满足建筑设计的所有基本要求，包括布局的功能、美学和外观。

非常主观，但我的观点是:

体系结构 系统的总体设计，包括与其他系统的交互、硬件要求、整体组件设计和数据流。

设计 整个系统中一个组件的组织和流程。这还包括该组件用于与其他组件交互的API。

建筑就是设计，但并非所有的设计都是建筑。因此，严格地说，尝试区分架构设计和非架构设计会更有意义。有什么区别呢?视情况而定!每个软件架构师可能有不同的答案(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).

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

我同意其中的许多解释;本质上，我们认识到软件系统的架构设计和详细设计之间的区别。

虽然设计师的目标是在开发所需的规格中尽可能精确和具体;架构师本质上的目标是指定系统的结构和全局行为，就像详细设计开始时所要求的那样。

优秀的架构师会避免过度规范——架构不能过分指定，但要足够，(架构)决策只针对那些风险处理成本最高的方面建立，并有效地提供一个框架(“通用性”)，在这个框架内可以进行详细设计，即局部功能的可变性。

实际上，体系结构过程或生命周期只是遵循这个主题——足够的抽象级别来概述(体系结构上的)重要业务需求的结构，并将更多细节留给设计阶段以实现更具体的可交付成果。

我的提醒:

我们可以不征求别人的意见就改变设计 如果我们改变架构，我们需要将其传达给某人(团队、客户、涉众……)

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