分享core3.1webApi领域驱动设计框架Ocean3D
1.前⾔
我是2012年就注册了博客园账号，后来之前的账号在⼀次事故中被注销了，⼜注册了新的账号，来博客园8年时间我没有发布过⼀篇博⽂，⾮常的惭愧，⼀直在默默的跟着⼤佬们学习技术。今天我也要回馈⼀下园⼦⾥的⼩伙伴，把我搭建的⼀套DDD框架分享出来，分享的⽬的是帮助⼀些⼩伙伴们学习 core 的基本知识和领域驱动设计的要点。再次声明领域驱动设计的核⼼是领域的划分已经领域的建模，领域驱动的思想远⽐代码重要。框架的搭建参考了微软、 .
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 命令查询职责分离我的理解就是把查询和命令分开实现。利于分类管理
应该直接在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)）被曾为事件溯源。
最后总结
我承认我的博客写的很懒，对领域设计的讲解也⽜头不对马嘴，⼤家还是看代码学习把，在吐槽⼀下写博客真的很累，我以后也需要好好学习写⽂章的技巧，怎么才能把我的想法，技术转化⽂字阐述给⼤家，在这⾥致敬每⼀个坚持写博客的博主，是你们的坚持让我们更加认识代码的世界。隋唐英雄排名榜
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论