28 | 控制流（上）：通过iam-apiserver设计，看Web服务的构建

总结： 介绍了 internal/pkg/apiserver 内部的组织结构 1. 最外层的Go文件主要完成： 1. 构建应用框架（app.go） 2. 提供应用框架执行时，需要的Run函数（run.go） 3. 创建 apiServer 服务实例（server.go 和 grpc.go） 4. 创建路由规则，安装中间件等（auth.go, router.go） 2. config 对应**应用配置** 3. options 对应命令行参数和配置文件。 4. controller、service、store 三个层次，controller 负责参数解析、校验；service 层负责业务逻辑；store负责数据库操作。 4层模型，模型层、控制层、业务层、存储层。层级之间如何解耦？ 1. 通过 interface 实现解耦； 2. service层和store层的实例，是在请求执行过程中动态创建，它们都依赖一个工厂对象，作为实例化的输入。 3. 工厂对象 store store.Factory 不与具体的表、具体的操作绑定，通过store对象，你可以执行数据库的任何操作。类似的，srv srvv1.Service 工厂也不与具体的业务绑定，通过srv对象，你可以执行任何业务逻辑。 服务启动流程分为三个阶段：配置阶段、PreRun阶段、Run阶段。配置相关的对象有：Options、Config、HTTP/GRPC 相关的配置对象。

var _ UserSrv = (*userService)(nil) 我是go初学者，这种语法表示没看明白

结合前面章节的铺垫，介绍iam-apiserver的使用方法、架构和代码实现，前后连贯，逻辑清晰，简洁易懂。 顺便一提，跟郑晔老师的《软件设计之美》中讲到的：快速了解一个项目时，要了解项目的模型、接口、实现，核心思想如出一辙。软件设计的路上，殊途同归。

练习1：通过component-base共享 REST API 相关代码

这里使用到了设计模式中的工厂方法模式。Service是工厂接口，里面包含了一系列创建具体业务层对象的工厂函数：Users()、Secrets()、Policies()。通过工厂方法模式，不仅隐藏了业务层对象的创建细节，而且还可以很方便地在Service工厂接口实现方法中添加新的业务层对象

老师，请问下context作为参数一直传下去的目的是什么呢

业务层和仓库层那里都做了两层抽象，比如仓库层有 Factory 和 SecretStore 两类接口，业务层调用的时候要这样写 s.store.Secrets().Create()。我的疑问是 Factory 这层抽象是不是可以省掉，业务层调用直接这样写 store.Secrets(dbIns).Create() 貌似也可以，这样有什么缺点吗？

老师，您好，在app/app.go 中 func NewApp(name string, basename string, opts ...Option) *App内部执行Option的方法，其实就是给App设置参数。为什么不来个set方法直接设置，现在这种设置方法感觉绕了一圈。。。。。

这里使用到了设计模式中的工厂方法模式。Service是工厂接口，里面包含了一系列创建具体业务层对象的工厂函数：Users()、Secrets()、Policies()。通过工厂方法模式，不仅隐藏了业务层对象的创建细节，而且还可以很方便地在Service工厂接口实现方法中添加新的业务层对象 老师，我感觉这里更像是抽象工厂方法模式

api接口是在哪里注册到router上面的啊，没找到，比如/v1/secrets/