BSS项目总结 · Asa · 个人手记

真正意义上在公司接手的第一个项目，在这星期五的时候，应该算是弄完了。尽管就只是普通对数据库的 CRUD，但仍然还是学到了很多。

业务方

从业务方面来讲，我负责的 BSS 的商品服务模块，需要了解电商的基本概念，SPU、SKU、Spec 等概念。

同时，还需要将当前场景提取抽象化的元素，在满足商品定义的基础上，做的高扩展性。

还有定义好自己的商品属性后，再与项目经理对谈，用于判断是否自己的设计可以满足对方的需求。

架构方

从架构方，真正的见证并参与了一个项目从零到一的过程，从概要设计到详细设计再到具体实现的流程。

深刻认识到了只要设计的到位，写代码就非常轻松，相反，如果设计写的非常模糊，coding 的时候，就很痛苦，因为没有明确的目标。

技术方

在写 go 代码的时候，收获第一点，整个项目的代码布局值得学习：

|--cmd         // main 函数主程序区，放到 cmd 的好处在于，一个项目可以有多个 main 函数实现不同的功能。
|--conf        // 顾名思义，存放 配置文件的区域，例如 mysql 地址，用户名以及密码等等
|--controller  // controll 层存放的校验逻辑，判断是管理员还是普通用户，然后根据相应的角色做一定的权限控制。还有就是校验 所传参数的合法性，不合法的参数直接 error
|--lib         // lib 层则是存放一些自定义的库，例如连接和操作 mysql 的相关函数，一些常用的数据转换等。
|--model       // 则是对数据库中单个表或者多个表联表的 CRUD 操作
|   |--dao     // dao 则是定义的一些模型的 struct 结构，我常常感觉 这个才是 model 层， 上面的 model 层才是真正的 dao 层。
|--service     // service 层那就很简单了，组合model 中的多个表的 CRUD，形成一个个业务所需的服务。这一层，很像搭积木，用 model 层的"积木"，搭建自己所需的"物品"。

收获的第二点，尽管有 conf 配置文件。但是在实际情况中，部署代码并不是go run main.go的将项目启动，而是在docker中运行，因此有些配置，需要因地适宜做一些修改。

所以在代码逻辑中，第一优先级是环境变量，如果相应的环境变量为空，则使用配置文件中默认的配置。

收获的第三点，

无论在 model 层，还是在 service 层，还是在 controller 层，都需要先定义接口，再对它做具体的实现。

以往只在 java 中这么干过，在 golang 中，知道有这个 duck 实现方式，但是并没有将其运行到代码中，之前只是存在于练习模式中。

这次在项目中使用的先定义后实现的模式，真香。

第一点，便于合作开发，尽管这个项目是我独立完成的，但是并不妨碍这个优点，预先定义好接口后，各个层级可以实现并行开发，各个层级之间解耦。

第二点，是非常方便的知道了当前这个文件它的作用，以及实现了哪些功能，一目了然。

第三点，其实在这个项目中也没有用的，那就是 duck 类型的优点。

收获的第四点，

是可以叫封装性比较强么？也不知道封装性这个词描述的是否准确。在这个项目中，详细的来说，model 层接受 sql.Tx 参数，然后实现相应的CRUD代码，然后生成这个 sql.Tx 以及当调用失败时的回滚处理，都在 service 层。

在 service 层有很多的函数嵌套关系。

// model 层
func InsertCate(..., tx *sql.Tx) error {
  ... 
  tx.ExecConent(...)
  ...
}


// service 层
func AddCate(....)(...){
  sql.tx 生成 tx {
    model.InsertCate(...,tx)
    model...(...,tx)
  }
}

我想了一下，这么做两点原因：

这是将 model 层的共性提取到 servcie 层，由service层实现能减少大量代码；
还有一个原因，这些 model 层的功能是统一为一个服务而工作，如果 model 层一个函数执行不了，那就意味这这个服务无法执行成功，同时回退这次服务的所有数据。如果在 model 层生成 tx，当服务的最后一步出错，只会回退最后一个 model 的操作数据，而上面几个model 修改的数据则无法回滚了。

收获的第五点

这一点，其实也不算是收获，在博客中也用到过这种技术，这次差不多算是强化了一下，那就是链式调用，很优雅的一种 coding 模式。同时也用到了 Functional Options 的编程模式，写完以后给人的观感极其的优雅，舒服。

具体的用法和介绍，可以推荐一篇酷壳写的博客：https://coolshell.cn/articles/21146.html

收获的第六点

最后的程序是要通过helm 的chart 部署到 k8s 集群上，所以这次也算是巩固了一下 k8s 的知识。

业务方

架构方

技术方

END