简单介绍基于core + ddd的分层架构

本文已参与「新人创作礼」活动.一起开启掘金创作之路。

简单介绍基于core + ddd的分层架构

不知不觉，都已经毕业好几年了，技术一直在迭代更新，从最初的WebForm，到后来的MVC3，一路升级到现在的MVC5；ORM也从之前的ADO.Net，到EntityFramework Model First，到现在使用的Dapper或者SqlSugar；随着业务的不断延伸扩展，项目原来的三层架构越来越觉得不够用了，借着项目转core的机会，干脆把项目改成DDD的分层结构。

引文
DDD（Domain Driven Design，领域驱动设计），它是一种架构设计思想，以业务为倒向，它的一大好处是不需要使用特定的架构，由于核心域位于限界上下文中，我们可以在整个系统中使用多种风格的架构。

它的专业术语有很多，其实我也不是完全的理解，好用就行。

基于健康屋的项目框架作以介绍：

分层说明

详细架构

架构详解

基础设施层 为 上层（Domain、Application等） 提供了一些基础建设，如ORM选型（SqlSugar、Dapper、FluentData），系统常量，缓存Key配置，系统枚举定义，事务的实现封装，甚至可以定义仓储接口基类 及其基本实现。

• Common
  工具层放的是 各种扩展方法（枚举操作、缓存、Model验证等）；及 各种操作帮助类（Excel、文件、网络请求、短信、加解密方法、腾讯云Cos操作等）
• Infrastructure.DB
  Infrastructure.DB是对SqlSugar（ORM）的功能封装，包括简单的CRUD，及分页查询、事物查询等
  如果项目ORM选型并非SqlSugar，则需要编写相应的封装类库，如Infrastructure.Dapper、Infrastructure.EF；或数据库服务器不同导致的语法的稍不一样，都可能需要重新编写，如Infrastructure.EF.Oracle来替代Infrastructure.EF。只要保证向上提供的接口一致，则项目代码改动的地方应该不多

（说明：DDD官方定义是Application、Service、Repository这三层的具体实现称之为Infrastructure）

• Domain
  领域层定义了领域对象（Entity、DTO、VO、BO）、领域仓储接口的定义、领域服务接口的定义
  （说明：Domain建议可以分的更细：领域对象、领域仓储接口、领域服务接口）
• Repository
  领域仓储实现层，负责单表的CRUD
• DomainService
  领域服务实现层，负责多表操作 应不包含复杂业务
• Application
  应用层 内含业务逻辑（接口和实现都在这一层）
• Web.Core
  Web通用核心层 可以定义 通用的过滤器（异常拦截、访问日志记录、登录状态验证、权限验证等）等
• Web API
  关于向下调用有两种方案：一种是每一个Request都对应Application中的一个方法，业务逻辑都写在Application里（比较官方）；另一种是可以直接调用DomainService和Repository，逻辑直接写在Controller里。虽然第一种比较官方，但在实际开发过程中，会显得较为繁琐，所以一般会选择可以绕过Application。