微服务**(gRPC)**
微服务负责处理业务，同时会和其他的微服务与各种外部依赖通信，微服务架构的核心是整洁架构，在这个项目中，一个微服务会被拆分到cmd(entry)、api、internal，cmd所做的事与gateway大致相同，也是进行初始化和依赖注入，api隔离了cmd与internal，而主要的业务处理在**internal中**
• 在传统的三层架构中（handler-service-dal），通常 dal 为核心。项目的依赖关系如图二：
当dal 这一层改动（指实现的改变），会导致 service 层和甚至 handler都需要改变，甚至连单元测试也要改，非常的麻烦，对于大项目，高耦合是不可接受的，UseCase 层的单测用内存假实现**/仿真仓库**，不需要启动 DB
• 而这是我们项目大致的整洁架构示意图（图三）
• api**：隔离外部协议层与业务层**(grpc_gen后需在internal实现接口)
• Application: 编排业务逻辑，返回结果，Application只需要调用 repository 中定义的接口，又或者是经过core service 聚合过后的方法
• domain
￮ models,error,constant：定义了基建层与应用层通用的对象**(特别是models，可以说是层与层之间约定的数据形式)**
￮ repository：外部依赖的接口，供application与core service调用
￮ core service：核心业务，会涉及到复杂逻辑，即对多个任务进行聚合后提供给application调用(verify是负责参数校验的)
• infrastructure：
￮ 实现 domain-repository 中定义的接口，来与外部依赖进行交互
￮ rpc：初始化调用其他微服务的gRPC client，调用其他的微服务并处理返回结果（rpcCli是interface，直接调用）
整洁架构的细节
• domain层core service负责实现逻辑的内聚，application层则是实现了逻辑编排的作用
• domain层的core service是无状态的（但models有业务数据这一状态），也就是固定的传入，固定的输出，没有管上下文，负责的比如verify 、还有涉及到业务上的条件判断(ttl+phoneLoginGetOTPInterval > phoneLoginOTPTTL，但我认为if ok和if err并不算业务上的条件判断，还是可以属于application)、复杂业务
• application是有状态的，因为起到了传入req和传出resp的作用，而不是让api层也通过models和application通信
• application操作领域对象，但不执行业务判断，只进行业务编排，具有处理上下文的能力，管该做什么
• domain层的core service是无状态的，只管怎么做，复用只是无状态的一个特性
• 例子：
比如IsCacheExist,Get(a Entity),Get(a Entity)FromRedis，如果没涉及到什么复杂的情况，那么application层就可以直接调用domain层repo定义的接口
Go //application ok:=IsCacheExist if ok{ e=GetFromRedis }else{ e=GetFromMySQL } convert e toProto
但是如果说是像支付系统,订单系统那样需要多重保障，会涉及到复杂逻辑，这时application就需要domain的core service来对逻辑进行内聚了
Go //application ok:=IsCacheExist if ok{ e=GetFromRedis }else{ e=GetFrom... } convert e toProto //domain core service func GetFrom...{ rpcRepo... SqlRepo... redlock... SqlRepo... }