如何开发一个可读性高的微服务？

1. Handler，重点应该是对 Request、Response 以及 “状态机” 的处理。
   1. Request
      1. Request 数据的转换、解析、校验。
      2. 对数据合法性的校验放在 Handler 中更合适，这样对于不合法的情况可以快速失败。
      3. 对于数据不合法的情况，也可以记录下操作日志，这样可以降低排错成本，直接在前端页面上就能判断出错误原因。
      4. 对于数据不合法的情况，后端服务日志中必须记录，记录的服务日志以行为单位定义好格式，这样便于 Linux 命令搜索日志排查问题。
   2. Response
      1. Request 数据的封装。
   3. 状态机
      1. 状态机最好也在 Handler 直接确认掉，同样符合快速失败原因。
      2. 同时，构造出来的 Entity 可以作为 Service 的入参，这样就不用在 Service 中构建了，Service 中本来就有构建 Entity 的需求。
2. Service，可以理解为 DDD 中的一个 “聚合”，执行的是主要流程。
   1. Service 是事件、操作的核心业务逻辑流程的表达，如果一些异常场景的处理不是主干业务，建议不要放在 Service 中，避免影响 Service 主干业务代码的阅读体验。
   2. Service 的主流程可以先在方法注释中使用业务描述语言表达一遍，这样有助于代码的阅读和理解。
   3. 状态机的检查可以放在 Service 中调用 Entity 方法实现，因为状态机的检查涉及到了和数据库的交互。
   4. Service 可以定义为一个 interface，其中一个 interface 就是 dry-run 的实现，这样就有效解释了为什么需要设计为 interface 了。
3. Entity
   1. Entity 中的方法是 Service 主要流程中各个功能的具体实现，这些具体实现由 Entity 充血模型的方式来实现，将有助于 Service 中代码的简化，因为 Service 要表达的重点就是业务流程。
   2. 什么是 “主流程” ？什么是 “次要流程” ？这是一个区分写在 Service 还是 Entity 的重要原则。
4. ValueObject
   1. “值对象” 是生成之后不会变的对象，微服务架构中从其它微服务查询到的对象数据一般都符合这个特征，如果有变化的话就
   2. 创建之后不能修改的对象，需要修改的话需要重新创建的对象。微服务内部的一些状态类型、常量类型对象就属于 “值对象” 范畴。

如果能够做到这些的话，一个服务的代码可读性就能上一个台阶了；如果还想再上一个台阶的话，可以将 “六边形架构” 的思想引入进来。