1.前言
我是2012年就注册了博客园账号，后来之前的账号在一次事故中被注销了，又注册了新的账号，来博客园8年时间 我没有发布过一篇博文，非常的惭愧，一直在默默的跟着大佬们学习.net技术。今天我也要回馈一下园子里的小伙伴，把我搭建的一套DDD框架分享出来，分享的目的是帮助一些小伙伴们学习.net core 的基本知识和领域驱动设计的要点。再次声明领域驱动设计的核心是领域的划分已经领域的建模，领域驱动的思想远比代码重要。框架的搭建参考了微软 eshoponcontainers、 Equinox .
2.框架分层
1.Ocean.API 着一层不用多解释 web api 应用负责提供前端通讯接口。
2.Ocean.Application 应用层 主要负责解析前端的ViewDto 、中转指令、实现查询。
3.Ocean.Domain 核心领域层 主要实现领域事件 领域模型 请求指令等。
4.Ocean.Domain.Core 领域层辅助 主要实现一些 辅助领域层的类，比如仓储接口、值对象、BaseEntity、聚合跟等。
5.Ocean.Infrastructure 基础设施层 主要负责实现仓储接口、事件溯源、等
3.工具以及第三方工具
准备工具
Visual Studio Community 2019、SQLService
第三方程序包
ASP.NET WebApi Core 主应用程序
Entity Framework Core 3.1 数据操作 主要完成命令操作
Dapper 数据操作 主要完成数据查询
AutoMapper 实体映射 主要完成 ViewDto 到 domain Model 转换
FluentValidator 实体验证负责前端ViewDto的验证相关。
MediatR 事件发布 订阅 推送 实现 领域事件 CQRS 读写分离
Swagger UI 接口展示供前端查看
AutoFac DI容器 依赖注入
serilog 日志记录
Identity.JWT 身份验证
4.以领域驱动视角介绍框架
CQRS 命令查询职责分离我的理解就是 把查询和命令分开实现。利于分类管理
通过图上可以看出 在Service中 我们直接实现了查询的功能，如果是其他的 增删改操作 通过发送指令转到指令代码中去实现，说真的这个还不是很完美的CQRS，我觉得发送指令这一步应该直接在Controller 中发送。查询的操作使用了Dapper 很方便，最开始博主想用一个Dapper拓展使用 linq 表达式简化SQL 后来想了一下 还是直接写SQL 更加直观。
上面三张图片展示了Command所在的位子,命令其实也是为了领域模型服务的，所以他是领域模型的一部分，RegisterCommand我个人认为其实是一个参数传递的实体，负责给命令处理程序（UserHandle）传递信息。在Handle中 我们真正实现 增删改的业务逻辑。
领域划分我个人理解就是把我们业务中的模块归类，比如 发布博客、购买商品等，在我们的程序中就是建立相对的实体类确定聚合根。
领域事件 是在领域模型完成本职操作之后的副作用 比如 发布博客之后发用邮件通知关注你的用户 等。
上图中 左边我画出了我实现的几个领域模型 user Role 都是聚合根。右变的图展示了 User聚合根中实现的功能。所有模型类采用充血模型，充血模型就是把领域中的操作放在领域中。大家注意 this.AddDomainEvent(registedUserEvent); 这句话 就是 当用户注册完成之后发送领域事件 去完成之后的操作。稍后还会将这里的实现。
每一个领域模型都继承BaseEntity，在BaseEntity中 有关于领域事件的操作，AddDomainEvent方法只是把所有的要执行的领域事件放到集合中，然后在EF提交的时候统一执行领域事件，这个设计我觉得非常的棒，是我在微软的 eshoping 项目中搬运过来的。
事件溯源 记录每一次领域事件的上下文，用来追踪一个领域模型的每一个动作。
InEventBus被称为事件总线，负责发布事件的时候集成一些业务，这里就在推送事件的时候把事件的上下文记录下来（_eventStore?.Save(@event)）被曾为事件溯源。
最后总结
我承认我的博客写的很懒，对领域设计的讲解也牛头不对马嘴，大家还是看代码学习把，在吐槽一下写博客真的很累，我以后也需要好好学习写文章的技巧，怎么才能把我的想法，技术转化文字阐述给大家，在这里致敬每一个坚持写博客的博主，是你们的坚持让我们更加认识代码的世界。
