使用传统的分层架构,我们的所有依赖项都指向一个方向,上面的每一层都依赖于下面的层。传输层将依赖于交互器,交互器将依赖于持久层。
在六边形架构中,所有依赖项都指向内部——我们的核心业务逻辑对传输层或数据源一无所知。尽管如此,传输层知道如何使用交互器,数据源知道如何符合存储库接口。
概述
最近在想着写一个个人项目,但是在项目的结构上却犯了难,此时翻到了一个视频,采用Hexagonal architecture(六边形架构),也被称为Ports and Adapters,大致就是下面图片的结构:
一共分为三层:
Domain: 里面放的是处理的基本逻辑,可以理解为大纲,它决定着Application和Framework的选择和实现
Application::它协调使用我们的Domain代码, 通过位于两者之间的方式,调整从framework到domain的请求
Framework: 为外部组件提供交互方式,驱动通常放在左边,被驱动放在右边
我们需要注意的是:
- 高层模块不应该依赖于低层模块。两者都应该依赖于抽象。
- 抽象不应该依赖于细节。细节应该依赖于抽象。
- 在驱动侧,适配器依赖于端口,由应用程序服务实现,因此适配器不知道谁会响应其调用,它只知道有哪些方法是保证可用的,因此它依赖于抽象。
- 在被驱动侧,应用程序服务依赖于端口,而适配器则实现端口的接口,有效地反转了依赖关系,因为“低级”适配器(即数据库存储库)被迫实现应用程序核心中定义的抽象,这是“高级”的。
所以我们的项目目录会像这样:
例子
这里我们也能看出六边形架构的另外一个称呼:Ports and Adapters的原因,适配器实现端口(通常为接口),以达到代码解耦的作用,下面将以上面的目录进行具体的例子讲解:
完整代码:link
本项目很简单,就是实现一个简单加减乘除的运算和数据库保存,那么我们秉持着核心domain层统领一切,适配器实现端口的原则,我们先定义 ./ports/core.go:
package portstype ArithmeticPort interface {Addition(a int32, b int32) (int32, error)Subtraction(a int32, b int32) (int32, error)Multiplication(a int32, b int32) (int32, error)Division(a int32, b int32) (int32, error)
}
有了接口我们就得配以适配器 ./adapters/core/arithmetic/arithmetic.go:
type Adapter struct {
}func NewAdapter() *Adapter {return &Adapter{}
}func (Arith Adapter) Addition(a int32, b int32) (int32, error) {return a + b, nil
}func (Arith Adapter) Subtraction(a int32, b int32) (int32, error) {return a - b, nil
}func (Arith Adapter) Multiplication(a int32, b int32) (int32, error) {return a * b, nil
}func (Arith Adapter) Division(a int32, b int32) (int32, error) {return a / b, nil
}
这便是我们的核心逻辑,当项目慢慢变大时,核心层逻辑也会越来越多。
接下来就到了应用层,当我们实现了运算,那么便需要拿到结果,注意:此时还用不到sql,所以我们把目的写进 ./ports/app.go:
type APIPort interface {GetAddition(a int32, b int32) (int32, error)GetSubtraction(a int32, b int32) (int32, error)GetMultiplication(a int32, b int32) (int32, error)GetDivision(a int32, b int32) (int32, error)
}
之后适配器实现:
type Adapter struct {// depedencies injectionarith ports.ArithmeticPortdb ports.DBPort
}func NewAdapter(db ports.DBPort, arith ports.ArithmeticPort) *Adapter {return &Adapter{db: db,arith: arith,}
}func (api Adapter) GetAddition(a int32, b int32) (int32, error) {answer, err := api.arith.Addition(a, b)err = api.db.AddToHistory(answer, "addition")if err != nil {return 0, err}return answer, nil
}func (api Adapter) GetSubtraction(a int32, b int32) (int32, error) {answer, err := api.arith.Subtraction(a, b)err = api.db.AddToHistory(answer, "subtraction")if err != nil {return 0, err}return answer, nil
}func (api Adapter) GetMultiplication(a int32, b int32) (int32, error) {return api.arith.Multiplication(a, b)
}func (api Adapter) GetDivision(a int32, b int32) (int32, error) {return api.arith.Division(a, b)
}
然后就到了用依赖的时候了,也就是framework,本文就讲讲mysql的CRUD:
// internal/ports/framework_right.go
package portstype DBPort interface {CloseDBConnection()AddToHistory(answer int32, operation string) error
}
然后实现:
//internal/adapters/framework/right/db/db.go
package dbtype Adapter struct {db *sql.DB
}func NewAdapter(driverName, dataSourceName string) (*Adapter, error) {// connect to dbdb, err := sql.Open(driverName, dataSourceName)...
}func (da Adapter) AddToHistory(answer int32, operation string) error {stmt, err := da.db.Prepare("INSERT INTO history (data, answer, opration) VALUES (?,?,?)")...
}
之后我们编写测试文件,进行测试,通常情况一个适配器配一个测试文件
基本都创建好之后,如何连接呢?
我们在cmd文件中创建一个main.go:连接所有端口和适配器代码的地方,将依赖项注入到需要的层中,例如将数据库注入到framework层
这样实现了代码的解耦,例如我们想换一个数据库,只需要更换数据库名和数据源名,其余不需要修改,同时我们的业务逻辑也不需要了解特定的数据源限制
总结
所以总结一下优点:
- 能够封装数据源实现细节
- 长期稳定性和可扩展性,因为只需少许更改,所以在微服务部署失败时很容易回滚,也可以直接通过配置文件决定数据源
但是他也并不是silver bullet,我们应该多多检测层之间的漏洞,预防逻辑泄露等问题
参考文章&&学习视频
Ready for changes with Hexagonal Architecture
Hexagonal Architecture, there are always two sides to every story
How To Structure Your Go App - Full Course [ Hex Arch + Tests ]