协议层必须置于adapters或interfaces层，http/grpc/websocket等协议处理代码（路由、绑定、响应）不得进入usecase或domain；dto与domain实体须显式单向转换，时间字段用clock接口抽象，json/protobuf/db tag严禁出现在domain中。
协议层必须放在 adapters 或 interfaces 层，否则 domain 和 usecase 会随 HTTP/gRPC 协议变更而被动修改——这不是分层，是套壳。
HTTP controller 怎么写才不污染 usecase
controller 的唯一职责是：解析请求 → 调用 usecase → 格式化响应。它不能持有任何 infra 实例（如 *sql.DB、*redis.Client），也不能 import infrastructure 包。
- 构造函数只接收 usecase 接口，例如
func NewUserController(createUser CreateUserUsecase) - request binding 和 response writing 全部在 controller 内完成，
usecase输入输出类型必须是纯 domain struct 或自定义 error - HTTP 状态码（如
http.StatusConflict）只出现在 controller，usecase返回的错误必须是 domain 定义的（如ErrEmailAlreadyExists） - 别在 controller 里做业务判断，比如
if user.IsActive { ... }—— 这属于 usecase 或 domain 方法该干的事
domain struct 为什么不能带 json: tag 和 time.Time
加了 json:"id" 就等于把 HTTP 序列化逻辑钉死在核心模型上；直接用 time.Time 则把时区、格式化、Now() 行为耦合进业务规则。
- domain struct 字段只能是基础类型（
string,int64）、自定义枚举（type Role string）或 domain 内定义的值对象（type Email string） - 时间字段统一用
int64（Unix timestamp）或string（ISO8601）表示，生成和比较操作移至application层 - 若必须保留
time.Time，则定义Clock接口并在 usecase 构造时注入，避免调用time.Now() -
json:、protobuf:、gorm:等所有 tag 必须剥离，DTO（如UserHTTPResponse）才负责适配
gRPC / WebSocket 协议适配的关键约束
它们不是“更高级的 HTTP”，而是生命周期和调用模型不同的适配器——但依赖流向不能变：协议状态归 adapter，业务动作仍走 usecase。
- gRPC 的
.proto生成代码放adapters/grpc/pb，服务实现（UnimplementedUserServiceServer）放adapters/grpc，只调用 usecase 接口 - WebSocket 连接管理（心跳、广播、连接池）全在
adapters/ws，ConnectionManager持有 domain 实体 ID（如userID string），不持有 domain struct - 长连接中触发的业务动作（如“用户上线通知好友”）必须封装成明确的 usecase 调用，而非在 handler 里直接查 DB 或发消息
- 不要让 domain 实体实现
proto.Message接口——DTO 才该实现，且转换必须显式单向（mapToDomain()/mapToProto()）
最容易被忽略的是 DTO 和 domain struct 的指针混用：一旦 controller 把 &user 直接传给 usecase，后续任何对这个 struct 的修改都会穿透到 domain 层——必须用值拷贝或显式映射切断引用链。
