.NET及.NET Core系统架构

三层及多层架构 Multitier Architecture

ASP.NET N-Tier Architecture Schema

Visual Studio N-Tier Example

来源：https://dotnetdaily.net/featured/n-tier-architecture-asp-net

微软官方N-Tier 介绍：https://docs.microsoft.com/zh-cn/visualstudio/data-tools/n-tier-data-applications-overview

三层架构wiki

https://en.wikipedia.org/wiki/Multitier_architecture#Three-tier_architecture

https://en.wikipedia.org/wiki/Multitier_architecture

洋葱架构 Onion Architecture

四个洋葱架构（Onion Architecture）的原则：

应用程序是围绕独立对象模型构建的
内层定义接口。外层实现接口
耦合方向朝向中心
所有应用程序的核心代码可以与基础架构分开编译和运行

原文：http://jeffreypalermo.com/blog/onion-architecture-part-4-after-four-years/

洋葱架构有时也被称为端口和适配器（Ports and Adapters）架构，或者是六边形（Hexagonal）架构。不过Wade认为，后者应该是洋葱架构的一个超集。

核心（Core）层是与领域或技术无关的基础构件块，它包含了一些通用的构件块，例如list、case类或Actor等等。核心层不包含任何技术层面的概念，例如REST或数据库等等。
领域（Domain）层是定义业务逻辑的地方，每个类的方法都是按照领域通用语言中的概念进行命名的。对领域层的控制是通过API层进行操作的，而所有的业务逻辑都归属于领域层。这种方式保证了应用程序的可移植性，在不丢失任何业务逻辑的情况下替换掉整个技术实现。
API层是领域层的入口，它使用领域中的术语和对象。Wade提到：API层应该仅仅向外界暴露不可变的对象，以避免开发者通过暴露的对象获得对底层领域的访问，并任意修改领域行为。Wade通常会从API层开始编码工作，每个方法就是一个骨架，并且对应一个高层次的功能性测试。随后添加代码逻辑以使该测试通过，以此驱动领域层的编码实现。
基础架构（Infrastructure）层是最外部的一层，它包含了对接各种技术的适配器，例如数据库、用户界面以及外部服务。它能够访问所有处于内部的层次，但多数操作是通过API层进行的。但也有一种例外情况的存在，就是负责实现领域层中所定义的某些接口（译注：例如各种Repository的接口）。

洋葱架构中的一个重要概念是依赖，外部的层能够访问内部的层，而内部的层则对外部的层一无所知。

http://www.infoq.com/cn/news/2014/11/ddd-onion-architecture

整洁架构 Clean Architecture

依赖规则（The Dependency Rule）

同心圆代表的是不同层级的软件代码。通常当你更深一步思考构造你的系统的时候，你的系统就会在更高的层级。最外层的圈代表的是机制级别的系统。最内层的代表的是策略级别的系统。

最重要的一条规则是依赖规则（The Dependency Rule）。这条规则说的是：代码依赖只能使由外向内。换句话说，内层结构的代码不能包含有任何外层结构的信息。尤其是一些外层结构的名称不应该被内层结构的代码提到，比如函数名，类名，变量名，或者其他的系统实体的名称。

同样的，外层的数据结构不应该被内层代码使用，特别是那些由外部框架生成的数据结构。我们并不希望外部结构的任何东西会影响到内部结构。

实体层（Entities）

实体是用来封装公司的业务规则的。一个实体可以是一个带方法的对象，也可以是一些数据结构和函数。只要实体能被公司的不同业务逻辑部件使用，实体的具体表现形式是无所谓的。

或许你并不是想写公司级的架构，而只是想写一个简单的应用，那么这里实体就是指的应用的业务逻辑对象。它们封装了最通用的规则，并且当外部环境变化的时候，这些实体是最不需要被变化的。举例来说，比如在增加翻页需求或者是安全需求的时候，这些实体是最不应该被改变的。没有任何具体的应用需要改变实体层。

用户实例层（Use Cases）

这一层的软件结构包含了具体的应用业务逻辑。它实现了所有的用户实例。这些用户的实例由流入实体的数据流和流出实体的数据流实现，这些用户实例使得内层的实体能依靠实体内定义的业务逻辑规则来完成系统的用户需求。

我们不希望用户实例层的任何改变会影响到实体层。我们同样也不希望用户实例层会被外部的结构层，比如UI、数据库或者任何公共的框架，的改变而影响。这层应该是独立于这些概念的。

当然，必然发生的是应用的业务逻辑被修改会影响到用户实例层的代码和结构。如果用户的需求改变了，这层的部分当然会被修改。

接口适配层（Interface Adapters）

这一层的软件结构的目的就是进行数据的转换，将便于用户实例和实体层操作的数据结构变化成为最便于外部结构（比如数据库或者Web）操作的数据结构。比如GUI的MVC结构，表现器、视图器、控制器都是属于这个结构的。这层很可能是通过控制器将数据结构传给用户实例层，并且返回数据给表现器，视图器。

数据在这层会被转换，将便于实体层和用户实例层使用的数据转化成为持久层能使用的数据，比如数据库。这一层的代码并不需要知道任何数据库的信息。如果数据库是SQL数据库，那么，所有的SQL语言应当在这层被限制使用，特别是在这一层中与数据库有交互的代码部分。

当一些外部的服务需要与用户实例层和实体层进行交互的时候，这时候需要的数据转换也理所当然地放在这一层了。

框架和驱动层（Frameworks and Drivers）

最外层是由框架和使用工具组成的。比如数据库，Web框架等。通常你并不需要写很多代码就能达到与内层进行交互的行为。

这层表达的是所有的数据应该具体最终到达的地方。Web是数据的最终到达地，数据库也是数据的最终到达地。我们把这些东西放在最外层，它们几乎对整个系统的架构造不成什么影响。

原文：https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html

译文：http://www.cnblogs.com/yjf512/archive/2012/09/10/2678313.html

DDD领域驱动分层架构 Domain-Driven Design

四层架构

User Interface为用户界面层（或表示层），负责向用户显示信息和解释用户命令。这里指的用户可以是另一个计算机系统，不一定是使用用户界面的人。
Application为应用层，定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其它系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务，分配工作，使它们互相协作。它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。
Domain为领域层（或模型层），负责表达业务概念，业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层实现的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心，领域模型位于这一层。
Infrastructure层为基础实施层，向其他层提供通用的技术能力：为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件，等等。基础设施层还能够通过架构框架来支持四个层次间的交互模式。

传统的四层架构都是限定型松散分层架构，即Infrastructure层的任意上层都可以访问该层（“L”型），而其它层遵守严格分层架构

链接：http://www.jianshu.com/p/a775836c7e25

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。并不针对单一语言，思路都是可以通用，都是为了实现高可用的应用系统。