驾一叶之扁舟 举匏樽以相属
寄蜉蝣于天地,渺沧海之一粟。哀吾生之须臾,羡长江之无穷。
挟飞仙以遨游,抱明月而长终。知不可乎骤得,托遗响于悲风。

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

缘起

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

 

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

 

 


 

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

 

 

 

二、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领域驱动设计的相关说明,还是那句话,技术是用来改善生活的,没有一成不变的好框架,也没有一无是处的设计思想,关键还是看学习者是一个什么心态罢了,江湖渺渺,各位仁兄任重而道远呀,加油吧兄弟们~~~

 

posted @ 2018-10-18 12:57 老张的哲学 阅读(...) 评论(...) 编辑 收藏
作者:老张的哲学
好好学习,天天向上
好友榜:
如果愿意,把你的博客地址放这里
jianshu.com/u/老张
SqlSugar codeisbug.com
钰玺 studenty.cn