MarioLuo

@yuandj 谢谢 合并冲突那个确实用不习惯 凑合着用 说不定习惯了就好了

这个很强

@echoechoin 长撒样 有图吗

颜值很高 精致的不像开源软件 之前用 medis 很多开源软件刚开始都做的很好 慢慢因为没有盈利就没有更新下去了 希望作者能尽快找到盈利的模式， 可以考虑苹果版本上架付费版本合适的价格，然后海外推广，毕竟有收入才能持续更新。

服务拆分后各个服务之间通过 http 接口调用，那么第一个问题考虑的是要不要提供客户端?
第一种: 服务分为多个 maven 模块, 例如: user-api, user-provider, 优点代码复用, 缺点就是版本兼容，适合大量接口调用.
第二种: 调用方写代码调用，优点是按需写、灵活，缺点就是代码重复，适合少量接口调用.
第三种: 单独写一个 sdk 项目，优点是复用，缺点单独维护，也可根据 openapi 文档自动生成.

回到你的问题，如果使用第一种方式：
1. API 包种每个接口返回 VO/DTO, 不要直接返回数据库实体类，实体放在实现模块中，实体转换用 mapstract 即可。
2. Feign 中每个接口建议入参和返回都包装一个实体: UserAddReq, UserAddResp 以后便于扩展而不影响调用方，部分原子接口可不用包装比如根据 id 获取用户信息: Result<UserDTO> getUserById(@PathVariable("id") Long id);
3.因为我们是 bff 模式，原子服务的 service 层尽量返回实体，控制层包装转化为 DTO/VO;
4.目前我们是返回的 Result<?>, 然后 Result 里有个 tryThrow()方法，由调用方控制，灵活性更大，也可以用 Decoder 方式;

另外一个小地方命名冲突: 一般会在 bff 服务中请求响应都叫 XXxReqVO, XxxRespVO, 而在原子服务叫: XxxReq, XxxResp 。

我们实际中采用第一种和第二种混合: bff 服务调底层服务用第一种，相对独立或外部的服务调用使用第二种。

根据个人遇到的情况来看，大致是项目没有约定规范、不同开发按照自己的命名和风格随意、新人对项目不熟悉、偷懒对第三方返回数据没有转换，说白了还是技术水平问题，但是归根结底还是管理问题。我的建议了就是提出问题和后端人员，讲道理方式沟通。

@Emptyh Zara, 优衣库, Gap ，美邦 风格都比较好看，相对 Zara 风格更潮一点，可以都试试看

@Goooooos plantuml 好像没这么好看