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

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)

软件设计有更长的历史，而软件架构这个术语只有20年的历史。因此，它正在经历成长的烦恼。

学术界倾向于将架构视为更大的软件设计领域的一部分。尽管越来越多的人认识到Arch是一个独立的领域。

实践者倾向于将Arch视为高级设计决策，具有战略性，并且在项目中撤销可能代价高昂。

Arch和设计之间的确切界限取决于软件领域。例如，在Web应用领域，分层架构是目前最受欢迎的(业务逻辑层，数据访问层等)。Arch的低层部分被认为是设计(类图，方法签名等)。在嵌入式系统，操作系统，编译器等领域，这将是不同的定义。

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

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

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

区分建筑和设计的形象:

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

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

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

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

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

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

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

当您需要将较高体系结构级别识别的业务和功能投射到应用程序中时，软件体系结构最好用于系统级。

例如，你的业务是关于交易员的“盈亏”，你的主要功能涉及“投资组合评估”和“风险计算”。

但是当软件架构师详细描述他的解决方案时，他会意识到:

“投资组合评估”不能只是一个应用程序。它需要在可管理的项目中进行细化，例如:

GUI 发射器 调度程序 .．.

(因为涉及的操作太大了，需要在几台计算机之间进行拆分，同时仍然可以通过一个通用的GUI随时监控)

软件设计将检查不同的应用程序，它们的技术关系和内部子组件。 它将产生最后一个体系结构层(“技术体系结构”)工作所需的规范(根据技术框架或横向组件)，以及项目团队(更面向业务功能的实现)开始各自的项目所需的规范。

http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns

架构告诉您系统是如何布局的。一个传统的体系结构模式示例是3层系统，其中系统被分解为表示层、业务层和数据层。

领域驱动的设计促进了4层架构。表示层、应用层、域层和基础结构层。存储库模式位于域层和基础结构层之间。你的领域模型不应该知道任何关于基础设施的信息，同时也应该保持纯粹并独立于基础设施。这就是为什么我们有存储库来协调这两层。

存储库模式仍然是一个模式，因为它是一个可重用的解决方案，可以处理重复出现的问题。然而，只有当我们讨论架构时，存储库模式才变得相关。它在领域驱动的设计体系结构中有自己的角色和职责。它不是数学类型的一般解决方案，例如抽象工厂模式，可以应用于系统中的任何地方。