Skip to content

Latest commit

 

History

History
38 lines (37 loc) · 2.11 KB

backend-java.md

File metadata and controls

38 lines (37 loc) · 2.11 KB
Raw

  • 分层架构

    • 遵守 DDD 分层规则：
      • 接入层负责定义 API，不处理包括用例、领域在内的任何业务逻辑
      • 应用层负责处理用例相关的业务逻辑
      • 领域层负责最终的领域逻辑，做到可复用和可被编排
      • 跨聚合的调用逻辑放在 Application Service
      • 聚合内的业务逻辑放在领域层 Service
    • 每个领域模型对应一个 Entity 类，用于承载状态
    • 管理面相关的接口与 service 代码放在 admin 模块
    • 用户面相关的接口与 service 代码放在 business 模块
    • 领域相关的代码放在 domain 模块
    • 基础设施的配置代码放在 infrastructure 模块

  • 命名和风格

    • 应用层服务命名为XXXApplicationService
    • 领域层服务命名为[Domain]+Service，一个聚合根对应一个领域服务
    • 用户面接受 Restful 请求命名为 XXXController，管理面为 XXXManager
    • 接受 Event 请求命名为 XXXHandler
    • 命名风格避免冗余，例如 domainService.action(String id, ...., String operatorId)，连起来需要形成一句话
    • 如果注解为默认行为，不显示添加，比如 @Column 如果满足字段规则，则省略
    • ApplicationServe 形参顺序为：被操作对象的 id、request、operatorId
    • 禁止使用import *

  • 测试策略

    • API 测试负责正向场景，为集成测试；单元测试负责异常场景，为分层测试。
    • 一个独立的业务场景至少保证有一个API测试覆盖 Happy Path
    • 单元测试的重点是领域层的测试

  • redis 设计

    • 禁止使用 scan\keys 会造成性能低下 http://doc.redisfans.com/key/scan.html
    • 禁止存放需要持久化的数据，因为可能需要清理 redis 数据
    • domain service的更新操作去获取资源时直接从repo中取，不要从缓存中取
    • 如果某个接口操作了资源A，在资源A更新之后若需要获取资源A的值，不用从缓存中取值，此时事务未提交，取到的值会有问题

  • 日志规范

    • 所有的的错误地方需要打 error 级别的日志
    • 在关键的业务逻辑，例如支付完成后回调需要打印 info 日志