传统分层

MVC

远古时代的 web 项⽬：

当前后端分离成为主流共识：

MVC -> DLC

业务逻辑越来越复杂，拆成单独的 logic：

业务代码越来越多了，看不懂怎么办

贫⾎模式	充⾎模式
业务逻辑都在 logic 层内	要让 domain object 即 entity 有更多逻辑
Struct、Class 上没有任何逻辑，或只有少量逻辑	通过聚合来组合 entity 的逻辑

贫⾎模式代码示例

业务逻辑被埋没在存储业务中：

使⽤充⾎模式改造后

定义 Customer Repo：

SOLID 中的 DIP(Dependency Inversion Principle)

通过 DIP，我们可以做到依赖⽅向与程序控制⽅向相反

整洁架构 style

整洁架构

Uncle Bob 提出的整洁架构：

Uncle Bob 同时也是⾯向对象编程中的SOLID 原则的提出者

整洁架构的核⼼观点

不与框架绑定：业务不应该与某个 web 框架绑定，应该做到想换就换。
可测试：业务逻辑应该在没有 UI、database 环境、web server 等所有外部环境的前提下做到可测试。
不与 UI 绑定：不与具体的 UI 库绑定，项⽬应该做到随意切换外部 UI，⽐如可以将 web UI 替换为 console UI，同时⽆需业务逻辑做修改。
不与数据库绑定：可以把 Oracle 换成 SQL Server，也可以换成Mongo，换成 BigTable，换成 CouchDB。业务不依赖具体存储⽅式。
不依赖任何外部代理：你的业务应该对外部环境⼀⽆所知。

不与框架绑定

业务代码⼊⼝不应与任何协议绑定
框架代码(如 gin.Context)不要⼊侵到业务层

可测试

在没有 UI、database 环境、web server 等所有外部环境的前提下做到可测试。

Sql driver mock for Golang
Go monkeypatching
Redis client Mock
httptest
gomock
Testify
How to get a mock Etcd for unit test?

不与 UI 绑定

我们做的基本上都是前后分离的系统，不太容易与 UI 发⽣绑定：

不与数据库绑定

不与数据库绑定：可以把 Oracle 换成 SQL Server，也可以换成Mongo，换成 BigTable，换成 CouchDB。业务不依赖具体存储⽅式。

需要借助 DDD 中的 Repo 设计⽅式：

不依赖任何外部代理

没有外部 agent 也能启动，做到⽐较难。

⽐如你是不是经常会碰到：

没有配置下发的 agent 的环节，本系统跑不起来。
没有 service mesh 模块，本系统跑不起来。
没有 metrics 采集模块，本系统跑不起来。

DDD style

DDD 社区就是名词多

Entity
Value Object
Repository
Aggregate
Aggregate Root

ports && adapters

六边形架构，也被称为端⼝与适配器架构，所有外部类型都有适配器与之对应，外部通过 API 与内部交互。——《实现领域驱动设计-ch4》

Ports = interface
Adapters = instances

DDD 中的战术设计-Value Object(Value Type)

Value Type 是不可变(immutable)，可⽐较(comparable)的值
例如：
数字： 1，2，3；
字符串：“⼈⺠⽇报”，“⽕星探测”
结构体：var addr = address {“100010”, “xi er qi”, “33.133”, “21.3243”}

DDD 中的战术设计-Entity

Entity 的关键是其有 ID 作为唯⼀标识
Value type 则没有 ID
有 ID 意味着 entity 是可变(mutable)的，会随着时间更新

DDD 中的战术设计-Aggregate

• Aggregate 和 entity 设计上类似，也有 ID，也是可变(mutable)的
• 聚合可以⽤ entity + value object 构成，如右图
• 每⼀个聚合对应⼀个 Repo interfac
• 聚合需要对聚合内的数据⼀致性负责，可以认为聚合是数据⼀致性的边界
• 聚合之外的⼀致性采⽤最终⼀致性保证

Aggregate:

|
Repo：