代码阅读

未分类

关于技术优化

具体

package组织风格

目前存在两种

• 按职责建package
  比如，po,bo,dto,service,emnu,util

• 按业务建package，再按职责
  比如，account/service,account/po, employee/service,employee/po

疑问

关于facade和service

观察到
1. facade中包含service，也直接包含一些业务method
2. facade和service都会直接通过pigeon开放给第三方

目前项目中facade和service的关系是设么样的，有没有相关定义（什么代码放到sevice，什么代码放到facade，如何把握）

service层这样的的项目，代码分层的推荐最佳实践为：
1）门面层
此层是对外开放的api，rpc，接收request，返回response。request、response中会包含DTO，或者把response理解为广义的DTO。
门面层一般会将DTO拆开成BO，或直接将DTO或request传给service。service一般会返回结果（BO或DTO）给门面，门面转成DTO，返回给远程调用者

2）业务层
此层包含两大类代码，用于粘合的service以及核心业务逻辑busniess。
粘合层service被门面层调用，从DTO构建BO，然后顺序调用busniess，busniess返回业务计算结果（一般为BO）给service，service将结果返回给门面层或调用持久化层DAO/Repository
业务层busniess的特点是上下文无关。所谓的“上下文无关”，指的是不会被上层门面层的直接调用只接受service调用、只接BO的输入和输出、可以不用mock直接单元测试（可以直接在main函数中运行）、不直接调用dao层

busniess层的具体形式可以是service里的private函数，也可以独立建类，类似service，但是不对外开放，package一般在service下

3）持久化层DAO/Repository
按现有代码结构理解service是内部的粒度更细的业务逻辑（通常也会叫做busniess）。service可不依赖上下文环境（如request）独立进行单元测试（无需任何mock）。
而facade是希望通过pigen开放给外界的接口，是对各service的组合调用，粒度略粗

关于PO，BO，DTO

目前各项目中风格不一致：如order中rpc api的返回中都将结果转成了dto再返回的，而markting中会直接用bo返回给远端调用者，并没有统一