做Go项目时，分层和目录结构的规划像设计房间格局一样，哪间放衣服、哪间做饭、哪间睡觉，各有各的用途。搞对了住着就舒服，搞混了就会不停地乱。想让代码后续不混乱、好扩展，合理的架构和规划最为关键。下面我结合一些常见的Go项目场景，帮你一步步看出怎么设计更加顺畅。
一、为啥要分层？
分层其实是让你自己省心。大家都清楚房间里每个东西摆在什么地方，要用时很快能找到。业务逻辑与数据交互分开来放，各自独自运作。比方说，同样是处理订单的流程，先通过用户接口层接收数据，紧接着拿到逻辑层加工处理，最后交到数据库层存起来。每个过程都归于自己区域做自己该干的事儿。一开始习惯了这种"干净"的方式，后面不会自己搅乱自己。毕竟代码不仅仅是让机器读的，更是让人读的。一个项目扔给新人，立刻能看清结构，这个时候你就明白了前期规划的重要性。
二、怎么设计这三层？
最常用的三层架构，比较贴近常见Go项目：表现层、业务逻辑层、数据层。先从简单三层开始，以后业务复杂再叠加新的结构也不迟。这时你可以从自己的项目场景切入。搞个小模块简单体验三层结构，比如用户注册流程。页面提交用户信息进系统后，表现层抓住数据，但不去管别的事儿，把计算、校验、流程交给逻辑层去搞定，最后需要持久化，存进数据库的动作甩给数据层来处理。三个大模块的分工大致就是这么定。接下来的工作就是依照这个格局布置"家具"。
三、目录结构咋整？
搞懂分层，目录结构就是细活。Go有它的习惯，有时得多考虑一下日常使用习惯，要不总会显得别扭。给你看一个简洁的起始结构：
myapp/
├── cmd/
│ └── myapp/
│ └── main.go
├── internal/
│ ├── delivery/
│ ├── service/
│ ├── repository/
│ └── model/
├── pkg/
├── configs/
└── web/
这里每块怎么用，细细说来：
cmd/myapp/main.go：作为整个程序的门面入口，无外乎初始化一些配置和启动服务。整体别搞得太复杂，简单准备直接进入。
internal/delivery/：放Handler相关的东西，这地方接收请求。类似服务员接了菜单等后厨处理，具体怎么搞它不管。而具体下层会处理这些细节。
internal/service/：顾名思义，所有逻辑汇聚于此。管你是新业务还是复杂交互，通用逻辑、计算一应放这里处理，外卖做好之后最终交出来。Handler取到最终处理完的"菜"后直接交付客户。
internal/repository/：存取数据具体操作在此实现，跟数据库等底层技术层打交道。具体东西由上层的业务安排拿数据，然后通过这个入口找数据库拿。常常你就轻松点，find、save这类的接口在此归纳完了。不乱搞数据库代码。
internal/model/：这儿敲定实体结构，页面上想表现成什么样子，有了这个档你就是一盘下锅了的菜，均围绕它写代码。看着就很明白的一条主线。
pkg/：放内部通用工具函数之类的，每项目多少都有一大坨通用工具。定时任务模块、Hash算法函数等闲杂小工具或者独立出来供多处共用的东西，全都集中在里面。避免自己在代码里前面写了后面无处用。
configs/：这是个朴实的目录，几乎一个项目变得稍复杂时，大家都离不开配置。摆在这个文件夹不再头疼各种频繁变动的事，让项目开发更为合理。
web/：可以简单丢些网页有关的内容，类似模板静态资源、或者要通过页面渲染的东西也可以把它搁在这儿放好。整个目录一明了然还立体全面。
注意文件别埋太深，确保三层之内到的了任何应该到的地方，看久乱的结构你自己受不了，更别提别人也很难接着上手。
