01介绍Bob大叔在他的博客《CleanArchitecture》中提到，现在一些流行的系统架构都采用软件分层设计，它们都提倡以下五个规则：独立于框架，可测试，独立于用户界面，独立于数据库，独立于任何外部依赖。Bob大叔的架构设计遵循依赖规则。他画了一个同心圆图，共分为4层。同心圆由内向外依次排列。Entities,UseCases,InterfaceAdapters,andFrameworksandDrivers，这条规则规定依赖关系只能由外向内，内圈不关心外圈，外圈不影响内圈。但是，不要以为一定要分这四层。这里描述的四层只是一个例子。也许您会发现您的业务需要的不仅仅是这四层。关键是要遵循由外到内的依存规律。在这篇文章中，我们介绍了Go语言中干净架构的实践。02CleanArchitecture的分层设计参考UncleBob的cleanArchitecture的软件分层设计，我们将架构层分为以下4层：ModelsRepositoryUsecaseDelivery其中Models和Entities一样，都会在所有层中使用。我们可以使用所有对象的结构Body和方法，其他所有层中需要用到的变量、常量、函数都放在Models层。这也避免了循环导入的问题。在Repository层，我们可以把处理数据库的程序和调用微服务的程序放在这一层，只处理数据的输入输出，没有其他业务逻辑的代码。该层依赖于被操作的数据库或被调用的微服务。Usecase层，我们可以把业务逻辑代码放在这一层，它负责接收表现层输入的数据，处理完数据后，调用Repository层，将处理后的数据存入数据库或者传递给调用方微服务。反之，将数据库中的数据或调用微服务的返回数据进行处理，返回给Delivery层。该层依赖于Repository层。Delivery层负责展示处理后的数据，可以是RESTful、HTML或gRPC等多种形式。同时，它还负责接收用户输入的数据，并将数据传递给Usecase层。该层依赖于Usecase层。实际应用目录：.├──app│└──main.go├──go.mod├──go.sum└──todoList├──delivery│└──http│└──todoList.go├──models│└──todoList.go├──repository│└──mysql│└──todoList.go└──usecase└──todoList.go03层与层之间的通信层与层之间如何通信，除了模型层，其他层通过接口进行通信，比如Usecase层和Repository层之间的通信。Repository层定义接口并实现接口中的所有方法。Usecase层通过接口与Repository层进行通信。示例代码：typeTodoListRepositoryinterface{Create(ctxcontext.Context,t*Todolist)(errerror)}同理，Delivery层与Usecase层通信，Usecase层定义接口并实现接口中的所有方法。Delivery层通过接口与Usecase层进行通信。示例代码：typeTodoListUsecaseinterface{Create(context.Context,*Todolist)(errerror)}04总结本文介绍了cleanarchitecture的软件分层设计，通过一个简单的TodoList实践Go语言中的“cleanarchitecture”project》的架构设计。但是Go语言其实并没有标准的架构设计，我们可以尝试建立自己的标准。完整代码可以参考github。
