- ### 分层架构
	- 遵守 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 日志