Account的简单架构

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

　　

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

　　

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

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

　　

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

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

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

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

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