从壹开始微服务 [ DDD ] 之一 ║ D3模式设计初探 与 个人计划书

缘起

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

　　

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

 

　　我给这个项目取名：ChristD3，意思是圣诞节DDD，但愿到圣诞节的时候能够完结，由于年末手中工做比较多，因此不会天天都写，可是每周确定会有更新，也但愿你们能够多多提意见，为了.net 的生存环境点赞加油吧！其实若是你已经开完了我写的上一个系列，你会发现其实上一个系列已经有 DDD 的影子了，不信？看完本文你就会知道了。

 

简单强调：

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

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

三、本系列仍是沿用上一个系列的宗旨：旨在抛砖引玉，想要学会还得本身多思考，文中会有两本参考书，能够看看。

---

目录：

源码 Github

.NET CORE 源码:

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

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

 

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

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

 

 

---

 

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

 

 

 

2、DDD领域驱动设计的前世此生

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

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

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

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

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

若是感受上边的理解有点儿苦涩，这里举个栗子：

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

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

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

 

二、领域驱动设计总体架构

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

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

 

 

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

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

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

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 需不须要一个仓储，也就是一个聚合？

 

 

 

四、有哪些资料能够参考

书籍：

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

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

 

编者按：
一、本项目我是借鉴了 https://github.com/EduardoPires/EquinoxProject 来说解的，请支持原做者！由于他没有文档，因此我就写了这个系列。

二、可能你会说我是抄袭，可是我本身写的时候，结构不是这样的，我当时是这么写的（若是你和我下边的分层同样，那就证实我不是瞎说的了）：

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

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

 

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

一、特别鸣谢开源项目

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

 

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

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

 

三、固然还有平时争议最多的话题：

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

 

3、个人计划书中涉及到的相关知识

 Bingo：这里是个人一个初步设想，之后可能根据状况进行增删，其中不少我们在以前的项目里都已经说到了，到时候会简单说一下跳过，也正好温习下，好比 WebApi的建立，依赖注入的使用，Dto数据传输对象的概念，Swagger 接口文档的使用，这些你们是否是很熟悉，因此说，当时在写上一个项目的时候，已经用了一部分DDD的思想了，如今回想起来是否是感受本身棒棒哒。至于不懂或者没见过的，不要紧，之后都会懂得的。

一、知识点（补充中）

• 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  👉云服务发布

 

二、特性（补充中）

• 领域驱动设计（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）

 

 

4、开发环境与项目设想

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

 

    系统环境

　　windows 十、SQL server 20十二、Visual Studio 201七、Windows Server 2008 R二、Linux Ubuntu、

    开发环境

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

 

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

　　一、到时候确定会有一个 WebApi 项目，如何基于这个，能够再一次搭建一个先后端分离的前端框架，至于仍是 VUE，仍是 Angular 6，这个再说；

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

　　三、尽可能实现数据的读写分离；

　　四、实现 Dockers 的容器使用；

　　五、OAuth 2.0 权限等；

 

5、项目中的点滴

一、关于微服务

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

 

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

 

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

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

 

二、本文用到的知识点树

 

 

6、结语

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