为什么需要领域

之前在文章里讲过，所有架构都是在治理复杂度，一切好的架构都满足下面几个要求，抱着一样的目的（高内聚，低耦合）

• 可复用性：迭代成本低，改动少
• 可读性：代码清晰易于理解
• 可维护性：上手简单，易于维护

我们回顾了失血、贫血、充血模型的设计，其实很像历史上架构模式的演进

• cs架构（失血），所有的代码都围绕数据库设计编写，基本不可复用
• 三层式架构，分为接入层-逻辑层-数据层，对能力做了简单封装

领域的名词

实体和值对象

领域：往往就是业务的某一个部分，例如电商的销售部分、物流部分、供应链部分；我们用领域把问题圈在了一个边界内，着力于解决边界内的业务问题。领域可以有子域，子域也可以有子域，可以层层拆解问题到最细的粒度

实体：具有唯一标识、连续性（指的是属性可能会发生变化）

• 可能是一个人，一辆车，一次比赛
• 实体具有业务属性、业务行为和业务逻辑
• 一般用充血模型实现自己的逻辑
• 一般在数据库中对应表

1
2
3
4
5
6
7

// Person is a entity that represents a person in all Domains
type Person struct {
	// ID is the identifier of the Entity, the ID is shared for all sub domains
	ID uuid.UUID
	Name string
	Age int
}

值对象：不需要唯一标识、属性不可变

• 用于封装某几个属性，比如地址（省、市、县），交易（入款方、出款方、时间）
• 一般不具有业务逻辑，只有序列化和整体替换
• 一般在数据库中作为一张表，或者实体的一个json字段存储
• 大部分场景和实体可以互换

1
2
3
4
5
6
7
8

// 仅仅作为举例。一般情况下交易都需要交易ID
type Transaction struct {
	// all values lowercase since they are immutable
	amount int
	from uuid.UUID
	to uuid.UUID
	createdAt time.Time
}

聚合：