Clean Architecture背后的核心想法其实很简单：“非核心”应该依赖于“核心”。
怎么算“核心”？对于一个应用来说，最最核心的当然就是业务数据（及其结构）和业务逻辑。这些信息应该属于一个模块（也就是常说的Service层），在实现上，应该自成一体，对数据持有化（用什么数据库和什么driver）、用户交互（是通过RESTful接口还是说本身是某个桌面应用的一部分）、或者如何与其它服务模块如何交互（消息系统？HTTP请求？）等技术有任何假定和依赖。
举个例子，在设计业务数据结构的时候，比如创建一个用户的结构，常常需要有个Id字段。这时候，就算我们知道数据库会选用MongoDB，而驱动技术用的是Mongo Go Driver，也不能简单地把Id的类型做如下定义：
import "go.mongodb.org/mongo-driver/bson/primitive"
type User struct {
Id primitive.ObjectID
...
}
因为如此一来，“核心”的业务数据就对“非核心”的技术选择产生了依赖。万一技术选择发生变化，如从MongoDB改为MySQL，或者弃Mongo Go Driver而改选mgo，业务层就要做相应改动。
对上面这个问题，可以这么解决：
type UserId interface{}
type User struct {
Id UserId
...
}
另外一个类似的问题就是如何处理异常。不好的做法是不区分业务异常和技术异常。所谓业务异常，举个例子，当通过Id来查询用户的时候，也许与之对应的用户信息并不存在，这个可能性就是一个业务异常。而由于和数据库的网络连接中断，而发生的异常，就属于技术异常。业务异常通常是要反馈给终端用户的，而技术异常通常是内部异常，其具体信息一般不需要暴露给用户。如果是开发RESTful API，那么对于技术异常，简单返回500内部错误就行，具体的错误信息和原因，不要暴露给客户端（要假定我们的API是给不知名的客户端使用的），而是在日志中写明。
在开发业务层时，一般来说应该考虑服务中所提供的每个操作会产生哪些业务异常，并且为其定义专门的类型：
type NoUserForSuchIdError struct {
Id UserId
}
func (e *NoUserForSuchIdError) Error() string {
return fmt.Sprintf("no matching user found for id %v", e.Id)
}
在业务层里，应该使用如上的业务错误类型，而不是使用其他层（如持久层）的技术带来的错误类型：
func (s *UsersService) FindUserById(id UserId) (User, *NoUserForSuchIdError, error) {
return s.Repo.FindUserById(id)
}
type UsersRepo interface {
FindUserById(id UserId) (User, *NoUserForSuchIdError, error)
}
而在实现持续层时，我们要把具体技术里的相对应错误类型转换成我们自己定义的业务错误：
func (r *MongoGoDriverUsersRepo) FindUserById(id UserId) (User, *NoUserForSuchIdError, error) {
u := User{}
e := r.usersCollection.FindOne(context.TODO(), bson.M{"id", id}).Decode(&u)
if e == mongo.ErrNoDocuments {
return User{}, &domain.NoUserForSuchIdError{Id: id}, nil
}
return u, nil, nil
}
而在Controller层，也应该辨认这种业务错误，相应地设置HTTP status及报文Body。
...
u, noUser, e := c.service.FindUserById(id)
if noUser != nil {
w.WriteHeader(http.StatusNoeFound)
_ = json.NewEncoder(w).Encode(newErrorResponse(noUser.Error()))
return
}
if e != nil {
w.WriteHeader(http.StatusInternalServerError)
_ = json.NewEncoder(w).Encode(new500Response())
return
}
_ = json.NewEncoder(w).Encode(newNormalResponse(u))
值得一提的是，从开头的图可以看出，Controller层与持久层都是依赖于业务层的，所以上面的代码里，它们可以看到并使用定义在业务层的数据结构和错误。
有疑问加站长微信联系（非本文作者）
