架构、接口与数据

按实际责任使用本页约定。目标是清晰的所有权和兼容演进，而不是为了结构整齐引入额外层、服务或共享模型。

代码边界和失败行为

按内聚能力组织代码；启动组合、业务规则、输入适配和外部 I/O 应能分辨。先遵循框架原生结构，仅在真实复杂度需要时增加抽象。

在信任边界校验不可信输入；业务规则由拥有该规则的模块负责，授权检查靠近每个相关入口和数据访问点。输入格式合法并不代表调用者有权访问资源。

错误接口采用稳定类别和可操作状态。内部日志保留有用原因并去除秘密与个人数据。不得吞掉错误、从 stub 返回成功，或未说明就替换算法和服务商。

为并发数、队列、请求/任务时长、上传体积和资源消耗设定边界。超时、取消、连接关闭、优雅退出及重试副作用应有明确定义。重复执行需有幂等键或可验证的去重策略。

日期与带时区的瞬间要区分；涉及本地时区和夏令时的逻辑需测试边界。金额使用明确定义的币种、精度和舍入规则，避免用不受控浮点数实现精确金额规则。

API、SDK 与事件

每份契约都要记录发布者、消费者、身份认证、访问授权、兼容规则以及唯一权威 schema 或实现。代码生成的契约应能重复生成并检查漂移；拟议设计接口不得写成已实现功能。

适用时规定输入校验、错误格式、排序/分页、筛选、版本和弃用、请求大小、超时/取消、幂等和限流。生成客户端要针对明确版本的兼容契约，并至少进行有意义的生产者/消费者检查。

事件和后台任务说明生产者、消费者、事件 schema、顺序假设、重试上限、幂等/去重键、死信及重放策略。按实际消息系统行为考虑重复与部分失败；不能没有证据就声称业务效果 exactly-once。

数据所有权和迁移

明确哪个组件拥有存储、schema、迁移、备份和留存。服务访问其他服务私有数据时通过其接口，不因数据库共享而共享数据所有权。

对重要数据记录事务和一致性边界、唯一性、敏感分类、导出/删除、租户隔离、日志与备份保护。租户上下文须在 HTTP/RPC、消息、后台任务、数据库、缓存和对象存储等相关边界建立并验证。

有破坏性或兼容性影响的迁移，应说明旧/新应用并存顺序、表规模与锁风险、备份/恢复、成功信号和部分失败处理。优先采用兼容扩展、分批回填、验证后移除旧结构的过程；回填应有上限、可恢复或幂等。已在共享环境执行的 migration 不应改写。失败后可能需要向前修复或还原数据，不能默认承诺自动 down migration。

测试使用合成或妥善净化的数据。清空数据库、覆盖用户数据或改动线上资源属于明确边界操作，不能藏在日常启动脚本或测试清理里。