Account的简单架构

　　前几天，有园友私下问我，博客中的AccountDemo后端架构为何是那样的，是否是分层太多太冗余，故这里简单介绍下。先看解决方案工程截图：

　　

　　每一个工程的含义，见https://www.cnblogs.com/guokun/p/7082987.html。运行时，请求处理流程，这里再贴出来：

　　

　　这里，园友主要不解的是，为何会有两个接口层，Account.Repository.Contract和Account.Service.Contract，是否是太多了。最近几年，在后端架构中，出现了一种称之为六边形架构的架构模式，这货以前曾被叫作洋葱架构、端口适配器架构，反正你们知道都是它就是了。六边形架构的核心，就是应用程序业务逻辑处于架构的核心，而上层的视图、控制器、数据访问等，都属于基础设施，是用来辅助实现业务逻辑的，他们都依赖于核心业务逻辑。这些基础设施是易变或者说极可能被频繁替换的，例如应用层今天多是MVC，明天多是WebAPI，数据访问今天多是EF，明天多是Dapper，甚至CSRedis，MongoDB。。。

　　六边形架构最终要实现的效果就是，解耦应用核心业务逻辑与基础设施，其总体架构与依赖以下图：

　　

 

 

　　蓝色箭头方向表明依赖方向，而非运行时数据流向或请求处理流向，请特别注意。ApplicationCore处于整个架构的中心，周边都是依赖于它的，这也是这一层名称ApplicationCore的由来，其核心特征是：一、用用层及基础设施层都依赖核心业务层；二、业务逻辑保持不变，应用层或基础设施层，好比切库、切ORM、切应用层框架，随便搞；三、有别于传统三层架构，数据层提供什么，业务层就有什么或用什么，六边形架构是业务层须要什么，就定义什么契约，数据层就实现什么或提供什么。

　　介绍完了六边形架构，接下来回答，为何有两个接口层。本质上，Account.Repository.Contract和Account.Service.Contract两层契约均归属于核心业务层，Account.Service.Contract用于对应用层承诺，提供什么服务，Account.Repository.Contract和Account.Service.Contract则规定基础设施层必须给本身提供什么操做。若是你愿意，那么这两个接口层彻底能够融入Account.Service工程中，这都是没问题的，原本他们就属于业务逻辑的范畴，但我仍是把它单独分出来，不然即是应用层、基础设施层直接硬依赖Account.Service，一者过重，两者不符合将面向接口编程。

　　最后，说下，为何Account.Repository.EF仓储工程中，一个实体类，对应了一个仓储对象。严格来说，这么作是不合适的，设想一下，假如数据库表不少，那这里岂不膨胀得厉害。要弄明白这个问题，首先得知道仓储的由来。这玩意儿来自领域驱动架构，通常来说，一个仓储是一一对应一个聚合根，这个聚合根是业务上功能聚合的一系列领域对象的，例如一个学生，对应一个宿舍，同时这个学生是个高富帅，他他妈的比较花心，身边有N个白富美女友。若是系统要维护这么样一个对应关系或信息，这里学生就是一个聚合根。具体表如今代码中，直观看就相似一个复杂对象，这个复杂对象的最外边就是学生，里边嵌套啥宿舍啊，女友集合啊，什么的。正常状况下，应该是学生这个聚合根才对应一个仓储类的，什么宿舍，女友都不该该有仓储类（假设没有其余需求致使他们须要上升为聚合根）。解释完了聚合根，这里回到刚才那问题，为何搞成了一个数据库实体一个仓储类。主要在于，示例中抽象出了这么一个仓储基类：

这玩意儿是泛型的，由于后续仓储实现类想要用到其中的一些公用方法，实现这个基类时候，须要约定实体，因此为了偷懒，我就每一个数据库表或者领域实体一个仓储类了，仅此而已。

好了，园友提到的几个问题差很少就这样。