半步多 玄玉V笔记

白话领域驱动

2020-08-06
玄玉

本质

DDD(Domain Driven Design,领域驱动设计)本质是让服务高内聚低耦合

最终它落地的时候是按照领域的方式来进行拆分(因此领域的界定就很重要),所以它要解决的最核心问题就是怎么拆分的问题

至于其他的一大堆名词:上下文、聚合根、贫血模型、充血模型、领域专家等等…..

这些和DDD实际上并没有很强的直接关系,绕在其中只会对DDD更加云里雾里,而抛开领域这个概念来谈这些名词是没有意义的

另外,领域驱动设计的理念可以说一直都存在,只不过被包装成了各种名词(其实没啥本质区别,就是换个词儿而已)

DDD中的概念 日常开发中的概念
Entity实体 Model (也就是MVC里的M)
Service服务 Controller(也就是MVC里的C)
AggregateRoot聚合 Logic (也就是业务服务)

举例

有一句话叫:领域的认定,主要看两个功能之间有没有物理关系(有逻辑关系是正常的),没有,那它们就是两个不同的领域

在电商的场景中,用户和商品,它们有逻辑关系(用户购买商品),但没有物理关系,所以是不同的领域

下面同样以电商场景来举例

业务领域拆分

一级领域:用户、商品、交易、搜索、推荐、营销…..

二级领域:可能有,也可能没有

比如用户领域主要有三个功能:注册、登录、查询。注册是写操作,登录查询是读操作

很显然这个场景下写比读重要(注册失败就不会去登录了,但注册成功而登录失败了,这时几乎都会再登录一次或几次试试)

当用户模块服务压力较大时,就可以考虑拆分成注册服务和登录&查询服务,此时的注册、登录&查询就是两个二级领域

同理,商品可能也会细分为发布和查询两个二级领域(部署成两个独立的服务),搜索也可能分为建索引和查询两个二级领域

这往往是根据业务场景和体量来决定的(同样在数据库层面,也要考虑主从加集群)

至于三级领域,在企业中基本上很少有

这就是领域拆分的本质,注重的是Design(设计方式或方法),所以不存在框架的概念(包括ABP,严格来说算不上DDD框架)

数据库的拆分

比方说数据库分库分表

  • 分库(垂直拆分):数据量大时,做分库,拆分时就是按照业务领域来拆的(用户、商品、交易各自相关表分别独立到不同的数据库)

  • 分表(水平拆分):数据量更加大的时候,就会做分表,很显然这个时候不是按照业务领域来拆的(实际上这属于架构侧的拆分)

既然数据库可以这么拆,以此类推,业务服务也可以这么拆

所以微服务架构的落地,在业务侧按照领域驱动设计,在架构侧按照水平拆分设计(换句话说:它们在“道”的层面是相通的)


相关文章

Content