白话领域驱动

• 本质
• 举例
  • 业务领域拆分
  • 数据库的拆分

本质

DDD（Domain Driven Design，领域驱动设计）本质是让服务高内聚低耦合

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

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

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

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

举例

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

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

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

业务领域拆分

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

二级领域：可能有，也可能没有

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

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

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

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

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

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

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

数据库的拆分

比方说数据库分库分表

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

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

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

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