这是我参与「第三届青训营 -后端场」笔记创作活动的的第1篇笔记
主要是记录和测试一下~
今天主要记录的是Go语言上手——工程实践
老师以开发一个掘金社区话题页面为需求模型
主要需要实现展示话题（标题，文字描述）和回帖列表 暂不考虑前端页面实现，仅仅实现一个本地web服务 话题和回帖数据用文件存储
需求用例
浏览消费用户
ER图
建立话题实体和帖子实体，话题和帖子的属性，是一个一对多的关系，因此帖子中需要有话题的id
分层结构
数据层：数据Model，外部数据的增删改查 逻辑层：业务Entity，处理核心业务逻辑输出 视图层：视图view，处理和外部的交互逻辑
其实这是比较通用的一个分层模型，我们在做项目的时候也可能需要，因为这样可以做到一定的领域分工，其实会提高代码的可读性。 分层结构主要分为三个部分。数据层repository，逻辑层service，视图层controller。
数据层repository主要关联的是底层的数据模型Model。封装外部数据的增删改查。我们针对我们的需求，我们的数据会存在本地文件File。可以通过本地的操作来拉取话题。数据层repository主要面向的是service层，对service层透明，透明是说repository数据层会屏蔽下游的数据差异。也就是说，不管我们这个需求是file，或者数据存于数据库里，也可能是存在下游微服务中，这样的话，其实repository对service暴露的函数或者接口是可以不变的，就是service不需要关心具体底层数据的存储。只需要拿到repository返回到一个model数据就可以。
逻辑层service主要是通过接收repository的一些数据作打包封装，输出一个实体Entity的概念。对于本例子的需求的Entity，其实就是我们的话题页面。
再上一层是视图层control，control层主要是作为视图层可能就是对上游负责包装一些数据格式，比如说像类似于本例子的需求其实主要是会json格式化一个结果，做一些封装，然后我们通过API的形式最终访问。
当然这是一个最基础的一个分层结构模型，不同的项目可能根据实际的需要有不同层次的拆分，但大致的结构思路这样，在实际实验项目上也不用照搬，也要根据我们项目的一个复杂度或者说实验成本来考虑。
等到后续我们小组在做项目的时候继续记录~
