缘起

哈喽大家周四好！又是开心的一天，时间过的真快，我们的 《从壹开始 .net core 2.1 + vue 2.5 》前后端分离系列共 34 篇已经完结了，当然以后肯定还会有更新和修改，直接在文章内更新，并在文章开头做提醒，如果有大的改动或者新功能，会在目录页进行重点说明（可能简书的更新速度没有博客园快，如果有任何疑问，可以先看博客园的文章，就是上边的这个地址?）。如果你是刚看到我的文章，而且恰好对.net core 不是很明白，或者想了解下如何前后端完全分离的，可以先看看上一个系列，我已经把 .net core 和 vue 的内容明显分开了，同时也把 vue 的基础部分和入门教程两个部分进行说明，相信大家都能看的明白。

　　

　　关于这一个系列，我想了很久，本来想开下 React 系列的，但是群里的小伙伴的反映，.net 后端还有很多东西，而且好多小伙伴反映课本太苦涩，看不进去，文档又太少，国内的大神好像也不太照顾我们这些小学生，特别是很少通过代码的形式讲解，那所以我就开了这个系列，虽然感觉会坎坷波折，本系列会从一个空的 Solution 到一个 完整 Project 的过程，具体的会在下边的计划书中详细说明，大家可以一会儿了解下，当然，框架本来就很见仁见智，思想设计更是没有常规法去定义，可能会有人不同意，老张希望如果有不同意见，别仅仅只是点击一下反对，可以发表下评论嘛，也算是给 .net 生存环境做点儿贡献，当然这个是练习项目，实际情况还要按照公司的要求来写，甚至公司都用不到（但是可能会面试的时候问到），一些小伙伴就会问，那我为啥要学，嗯~~~要是这么问，我也不知道如何回答了 [苦笑] ，就好像健身一样。

　　我给这个项目取名：ChristD3，意思是圣诞节DDD，希望到圣诞节的时候可以完结，因为年底手中工作比较多，所以不会每天都写，但是每周肯定会有更新，也希望大家可以多多提意见，为了.net 的生存环境点赞加油吧！其实如果你已经开完了我写的上一个系列，你会发现其实上一个系列已经有 DDD 的影子了，不信？看完本文你就会知道了。

简单强调：

1、本系列重点通过代码进行说明，那些苦涩的概念可能比较少，特别是本文，是简要说明，具体的详细内容在之后文章中体现。

2、本系列只是对知识点进行讲解，重点在说明新知识上，只是一个很小的框架，数据也很简单，可能还是一个简单的个人博客之类的，请不要和企业级项目对比。

3、本系列还是沿用上一个系列的宗旨：旨在抛砖引玉，想要学会还得自己多思考，文中会有两本参考书，可以看看。

---

目录：

源码 Github

.NET CORE 源码:

Github:  https://github.com/anjoy8/ChristDDD

Gitee :   https://gitee.com/laozhangIsPhi/ChristDDD

以后更新的文章会在这里一一更新：

• 一 ║ D3模式设计初探 与 我的计划书
• 二 ║ DDD入门 & 项目结构粗搭建
• 三 ║ 简单说说：领域、子域、限界上下文
• 四 ║一个让你明白DDD的小故事 & EFCore初探
• 五 ║聚合：实体与值对象 （上）
• 六 ║聚合 与 聚合根 （下）
• 七 ║项目第一次实现 & CQRS初探
• 八 ║剪不断理还乱的 值对象和Dto
• 九 ║从军事故事中，明白领域命令验证（上）
• 十 ║领域驱动【实战篇·中】：命令总线Bus分发（一）
• 十一 ║ 基于源码分析，命令分发的过程（二）
• 十二 ║ 核心篇【下】：事件驱动EDA 详解
• 十三 ║ 当事件溯源 遇上 粉丝活动

---

一、今天要实现红色的部分

二、DDD领域驱动设计的前世今生

好多小伙伴都在说，听DDD都听了好几年了，感觉就像是空气一样，一直在身边，可是一直摸不着，虽然有时候用到一些，可都是无法具体深入的对其描述和总结，那领域驱动设计到底是怎么来的呢，在早期项目开发中，我们主要就是单系统来进行开发，很多的模板都是揉在一起，其实现在咱们平时用的最多的MVC架构也有这样的问题，然后近来演化出的前后端分离，是从协同开发的角度方向去改善单系统问题，而DDD则是从后端整体框架中，对项目进行整合，剥离，细分和联系通讯等等，这样面向领域驱动设计就出现了。

1、DDD领域驱动设计知多少

首先要知道DDD是一种开发理念，核心是维护一个反应领域概念的模型（领域模型是软件最核心的部分，反应了软件的业务本质），然后通过大量模式来指导模型设计与开发。

DDD的一般过程是：首先通过软件需求规格说明书或原型生成一个领域模型（类、类的属性、类与类之间的关系）；然后根据模式（应该如何分层？、领域逻辑写在哪？与持久化如何交互？如何协调多对象领域逻辑？如何实现逻辑与数据存储解耦等）指导来实现代码模型。

DDD中最核心的是Domain Model（领域模型），和领域模型相对的是事务脚本。领域模型和事务脚本说到底就是面向对象和面向过程的区别。

如果感觉上边的理解有点儿苦涩，这里举个栗子：

我认为任何一个系统都会属于某个特定的领域，比如论坛是一个领域，只要你想做一个论坛，那这个论坛的核心业务是确定的，比如都有用户发帖、回帖等核心基本功能。比如电商平台、普通电商系统，这种都属于网上电商领域，只要是这个领域的系统，那都有商品浏览、购物车、下单、减库存、付款交易等核心环节。所以，同一个领域的系统都具有相同的核心业务，因为他们要解决的问题的本质是类似的。

因此，我们可以推断出，一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以，只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。

关于电商系统大家肯定都很了解了，什么商品模块，用户模板，订单模板，等等等等，这个就是领域模型的一个体现，网上看到一个很好的文章，他对普通电商的订单中心进行建模，如图：

2、领域驱动设计整体架构

那从整体架构上来说，主要分成以下四个部分，具体的在下一讲的项目整体搭建中会详细说明：

• Presentation Layer：表现层，负责显示和接受输入；
• Application Layer(Service)：应用层，很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；
• Domain Layer(Domain)：领域层，包含整个应用的所有业务逻辑；
• Infrastructure Layer：基础层，提供整个应用的基础服务；

DDD领域驱动设计的优点就包括：

1.从技术维度实现分层：能够在每层关注自己的事情，比如领域层关注业务逻辑的事情，仓储关注持久化数据的事情，应用服务层关注用例的事情，接口层关注暴露给前端的事情。

2.业务维度：通过将大系统划分层多个上下文，可以让不同团队和不同人只关注当前上下文的开发。

3.时间维度：通过敏捷式迭代快速验证，快速修正。

3、如何划分领域聚合

这里随便举个栗子：

公司部门权限小系统，用户表 User、角色表 Role、用户角色关系表 UserRole、部门表 Department、菜单表 Menu、菜单角色关系表 MenuRole，共六个表，

首先呢，根据我的想法，只要对一个模型操作，就必须建仓储 Repository ，那它就是一个聚合，所以：聚合和仓储基本是一对一的，有一个仓储就是一个聚合。

所以现在有四个聚合了：

聚合1：Department

聚合2：Menu、MenuRole、Role 三个， 聚合根是 Menu

聚合3：User、UserRole、Department、Role 四个，聚合根是 User。

聚合4：Role、User、UserRole、MenuRole、Menu  五个，聚合根是 Role。

然后再从关系表中看，用户和角色是多对多的关系，所以需要把 UserRole 作为一个新的聚合

聚合5：UserRole、User、Role 三个， 聚合根是 UserRole

这里存个疑，MenuRole 需不需要一个仓储，也就是一个聚合？

4、有哪些资料可以参考

书籍：

2004年，Eric Evans的《领域驱动设计——软件核心复杂性应对之道》

2014年，Vaughn Vernon的《实现领域驱动设计》，个人推荐

编者按：
1、本项目我是借鉴了 https://github.com/EduardoPires/EquinoxProject 来讲解的，请支持原作者！因为他没有文档，所以我就写了这个系列。

2、可能你会说我是抄袭，但是我自己写的时候，结构不是这样的，我当时是这么写的（如果你和我下边的分层一样，那就证明我不是瞎说的了）：

应用层：除了Service和IService、DTO、还有使用 CQRS 方法的查询、接受的命令，事件驱动的通信（集成事件），但是没有业务规则；
领域层：这里主要放的是领域实体、值对象、聚合和事件模型、Bus等；
基础层：就是ORM的持久化相关；
U  I 层：显示页面；

不过我写的时候感觉凌乱，不适合大家初学者学习，所以就想着要改变一下，对比了Git上的各种大神结构，偶然发现了EduardoPires的代码，感觉很清晰，就按照他这个来了。

感谢以下文章对本系列的帮助：

1、特别鸣谢开源项目

https://github.com/EduardoPires/EquinoxProject，我基本都是在这个项目基础上，为了广大刚进入DDD的小伙伴的，因为直接看项目肯定看不懂。我从新建空解决方案开始，一点一点讲解的，做了这个系列说明文档，我要强调我是主要讲知识，Code还是要尊重原作者，但是我的核心是布道，是对他的项目讲解，因为没有Code，我也能讲知识点。

2、感谢平时遇到的特别好的文章（节选）

1. 领域驱动设计，为何又死灰复燃了？
2. ABP框架理论研究总结(典藏版)
3. 浅谈我对DDD领域驱动设计的理解
4. IDDD 实现领域驱动设计－CQRS（命令查询职责分离）和 EDA（事件驱动架构）
5. 领域驱动设计的实践 – CQRS & Event Sourcing
6. CQRS Journey

3、当然还有平时争议最多的话题：

1. Repository 仓储，你的归宿究竟在哪

三、我的计划书中涉及到的相关知识

Bingo：这里是我的一个初步设想，以后可能根据情况进行增删，其中很多咱们在之前的项目里都已经说到了，到时候会简单说一下跳过，也正好温习下，比如 WebApi的创建，依赖注入的使用，Dto数据传输对象的概念，Swagger 接口文档的使用，这些大家是不是很熟悉，所以说，当时在写上一个项目的时候，已经用了一部分DDD的思想了，现在回想起来是不是感觉自己棒棒哒。至于不懂或者没见过的，没关系，以后都会懂得的。

1、知识点（补充中）

• ASP.NET Core 2.1.2  ?基本框架
• ASP.NET MVC Core  ?实现mvc web页面
• ASP.NET WebApi Core  ?实现 api 接口
• ASP.NET Identity Core  ?身份验证
• Entity Framework Core 2.0  ?实现ORM数据持久化
• Dapper （待定）
• .NET Core 原生 DI  ?实现依赖注入
• AOP  ?面向切面
• Autofact（待定）IoC
• AutoMapper  ?实现Dtos
• FluentValidator验证
• Swagger UI  ?实现接口文档展示
• MediatR  ?基于内存级别的消息发布订阅
• Azure  ?云服务发布

2、特性（补充中）

• 领域驱动设计（Domain Driven Design (Layers and Domain Model Pattern)
• 命令查询职责分离（CQRS：Command Query Responsibility Segregation）
• 领域通知 （Domain Notification）
• 领域驱动 （Domain Events）
• 事件驱动架构 (EDA)
• 事件回溯 （Event Sourcing）
• 最终一致性 （Eventually Consistent）
• 工作单元模式 （Unit of Work ）
• 泛型仓储 （Repository and Generic Repository）

四、开发环境与项目设想

这里再强调下，这个系列只为了说明知识点内容，可能数据很少，框架很简单。

系统环境

　　windows 10、SQL server 2012、Visual Studio 2017、Windows Server 2008 R2、Linux Ubuntu、

开发环境

　　Visual Studio 15.3+、.NET Core SDK 2.0+、

如果顺利的话，会引入下边这些东西，如果上边讲起来很费劲，可能就顺延下去了：

　　1、到时候肯定会有一个 WebApi 项目，如何基于这个，可以再一次搭建一个前后端分离的前端框架，至于还是 VUE，还是 Angular 6，这个再说；

　　2、然后会有一个 MVC 项目，很简单，就是一个页面的展示，主要是为了讲解如何搭建 .net core MVC 项目；

　　3、尽量实现数据的读写分离；

　　4、实现 Dockers 的容器使用；

　　5、OAuth 2.0 权限等；

五、项目中的点滴

1、关于微服务

本文中，会涉及到CQRS和ES相关概念，这两点在以后的微服务中也会有所用处，而其中关于微服务管道的总线问题，我用的是 在命令管道中使用转存进程模式（内存中）。这种方式使用的是MediatR的中介者模式。

当然还有别人使用的另一种方式，消息队列 RabbitMQ 或者 KafKa 等，在命令的管道中使用消息队列（进程外）

参考：在 CQRS 微服务中实现读取/查询

使用 Web API 实现微服务应用层

2、本文用到的知识点树

六、结语

本文只是简单给大家见个面，初略说明本系列要说什么，以及DDD领域驱动设计的相关说明，还是那句话，技术是用来改善生活的，没有一成不变的好框架，也没有一无是处的设计思想，关键还是看学习者是一个什么心态罢了，江湖渺渺，各位仁兄任重而道远呀，加油吧兄弟们~~~