通过GO后端项目实践理解DDD架构

最近在工作过程中重构的项目要求使用DDD架构，在网上查询资料发现教程五花八门，并且大部分内容都是长篇的概念讲解，晦涩难懂，笔者看了一些github上入门的使用DDD的GO项目，并结合自己开发中的经验，谈谈自己对DDD的理解。

简要介绍

这里借用github老哥的一张图来说明，那些长篇大论就不叙述了，因为咱们主要是在代码中应用嘛，直接讲解在项目中要怎么写。

DDD主要分为几层，interface,application,domain,infrastructure

在DDD中的调用顺序是 interface -> application -> domain

可以类比MVC controller -> service -> model

可以发现DDD比MVC多了一个infrastructure层，这里用某张表的CURD来举例，这里的某张表在domain层中被称为某个仓储（Repository），其实就是这张表的CURD操作，只不过你在domain定义的是接口，接口中方法的技术实现在infrastructure定义。

也就是说你的业务规则在domain定义，业务逻辑中与其他系统(db，文件系统，网络，第三方库等)的交互写在infrastructure层。

举个简单的例子，对于用户表(用户仓储)，在domain层定义接口
internal/domain/user/user.go

// UserRepository 表示用户仓库接口
// 由基础设施层实现
type UserRepository interface {Get(ctx context.Context, id int) (*domain.User, error) // 根据ID获取用户GetAll(ctx context.Context) ([]*domain.User, error)    // 获取所有用户Save(ctx context.Context, user *domain.User) error     // 保存用户
}

要实现接口中定义的方法，就需要涉及到数据库(这里是Mysql)的CURD操作， Mysql不属于本系统，所以方法的实现放在infrastructure

internal/infrastructure/user/user.go

// userRepository 实现 UserRepository 接口
type userRepository struct {conn *sql.DB // 数据库连接
}// NewUserRepository 返回初始化的 UserRepository 实现
func NewUserRepository(conn *sql.DB) repository.UserRepository {return &userRepository{conn: conn}
}// Get returns domain.User
// Get 根据ID返回用户对象
func (r *userRepository) Get(ctx context.Context, id int) (*domain.User, error) {row, err := r.queryRow(ctx, "select id, name from users where id=?", id)if err != nil {return nil, err}u := &domain.User{}err = row.Scan(&u.ID, &u.Name)if err != nil {return nil, err}return u, nil
}// GetAll returns list of domain.User
// GetAll 返回所有用户列表
func (r *userRepository) GetAll(ctx context.Context) ([]*domain.User, error) {rows, err := r.query(ctx, "select id, name from users")if err != nil {return nil, err}defer rows.Close()us := make([]*domain.User, 0)for rows.Next() {u := &domain.User{}err = rows.Scan(&u.ID, &u.Name)if err != nil {return nil, err}us = append(us, u)}return us, nil
}// Save saves domain.User to storage
// Save 将用户对象保存到存储
func (r *userRepository) Save(ctx context.Context, u *domain.User) error {stmt, err := r.conn.Prepare("insert into users (name) values (?)")if err != nil {return err}defer stmt.Close()_, err = stmt.ExecContext(ctx, u.Name)return err
}

完成domain接口的定义以及实现后，相当于MVC的model层实现了，那么只需要在上层调用domain的接口就行了
DDD中的interface,application和MVC的controller和service层一样的，interface用于接收http请求，把参数传递到下层，application用于整合业务逻辑，把http接口需要的数据返回

internal/application/user/user.go 整合数据返回给interface层

// UserInteractor 嵌入了domain的用户CURD接口
type UserInteractor struct {Repository repository.UserRepository 
}// GetUser returns user
// GetUser 返回指定ID的用户
func (i UserInteractor) GetUser(ctx context.Context, id int) (*domain.User, error) {return i.Repository.Get(ctx, id)
}

internal/interface/user/user.go 拿到数据返回给前端

// Handler 用户处理器
type Handler struct {UserInteractor *application.UserInteractor
}// getUser 处理获取单个用户的请求
func (h Handler) getUser(w http.ResponseWriter, r *http.Request, id int) {ctx := r.Context()user, err := h.UserInteractor.GetUser(ctx, id)if err != nil {Error(w, http.StatusNotFound, err, "failed to get user") // 获取用户失败return}JSON(w, http.StatusOK, user)
}

一个简单的DDD架构就这样实现了

有几点经验

domain层的一个领域负责的是相关的业务，也就是对 /domain/xxx 这个目录，只要与这个领域相关的表都可以定义在该目录下
domain除了定义接口，相关的业务逻辑实现也要放在这里，比如对领域中的某些参数的校验，即在该领域定义的结构体绑定一些校验方法等，但是与第三方交互的具体技术实现都放在infrastructure
对于想采用CQRS的项目，一般是在application层分别定义查询实例和命令实例，把涉及到查询的操作都绑定到查询实例，把涉及到命令的操作都绑定到命令示例，可以读写分离，写操作可以写主库，读操作读从库