DDD领域驱动设计——概念和架构分层

前言 很高兴能开始新的系列,这次的章节是DDD领域驱动设计和微服务的概念与思想。 PS: 此系列文章的源码,没有很丰富的功能,没有非常完善的认证体系,不适合直

前言

很高兴能开始新的系列,这次的章节是DDD领域驱动设计和微服务的概念与思想。
PS:
此系列文章的源码,没有很丰富的功能,没有非常完善的认证体系,不适合直接用去企业开发。
此系列的文章,核心是突出DDD的思想,和微服务的思想。所以功能上会比较精简。
技术点:
CQRS+Event实现微服务,EfCore实现领域持久层。
源码地址:
https://github.com/SkylerSkr/Skr3D

1.DDD的思想

先讲解DDD的思想,领域驱动设计。以领域为核心推动程序的设计

数据库驱动:

我们在开发过程中,拿到一个新的项目,第一时间应该都是设计数据库。如果业务上需要增加个字段,那么就需要更改表结构。
缺点1:如果我们不同的业务,都对一张表进行了操作,那么我们改表结构的时候,就需要处理跟业务无关的代码。随着项目的增大,这种更改工作可能是巨大的。
缺点2:有一些操作可能跟自己当前的业务一点关系都没有。随着项目的增大,代码的可读性会越来越差。

领域驱动:

数据库驱动,随着项目的增大,业务逐渐的负责,后期的开发成本会几何倍的增长。所以就有了DDD的出现,我们从领域的角度解决问题,最后再解决持久化。
领域:
小编的公司是做酒店行业的,那就是酒店领域。设想一下,如果你到酒店入住,需要哪些流程呐?
领域事件:
网上预定,入住,退房,客房服务,点餐等等。这些在酒店领域内的业务就是领域事件。
核心子领域:
网上预定,入住,退房。是酒店领域一定要有的功能,这就是核心子领域。
支撑子领域:
客房服务,点餐等不影响主要功能的就是支撑子领域。
领域专家:
对该领域非常熟悉的人,你的项目经理,老板,行业资深的从业者等。

微服务的思想

传统项目:
在我们的传统的开发过程中,每次发布都需要发布完整的项目,耗时非常长,如果发布失败了整个程序都会停止。
微服务项目:
在微服务中,服务是最小的单元。我们把传统的项目分成多个服务,单独部署出去。单服务的更改和停机,对整个项目的影响就不会很大。而DDD天生适合微服务,因每个单独的领域,就可以是单独的服务。
微服务的实现方式:
因各个服务会经常发布,可能是增加服务,也可能是减少服务。所以服务发现和网关就是核心要点。
1.服务发现:发现有哪些服务正在运行。
2.网关:对接服务发现,判断请求进来,需要转发给哪个服务处理。

架构分层

项目分层图
01:UI层没啥说的
02:应用层,这里就充当网关的作用,用来决定请求进入哪个领域。
03:领域层,领域层只关心自己,不关心实现方式。所以将持久层的接口也放在领域层
Infrastruct:基础设施层,这里就提供一些基础的功能。也实现领域层的持久化方法。

架构图

架构图

您可能有感兴趣的文章
领域驱动设计(1)认识了解什么是领域驱动

领域驱动设计 Domain

什么是领域驱动设计(Domain Driven Design)?

领域驱动设计(Domain Driven Design)

从Axon到DDD领域驱动设计