产品架构与技术架构应该共享同一张问题地图

产品文档常按页面和功能组织，技术架构则按前端、服务、数据库和基础设施组织。两种视角都有必要，但如果没有共同对象，需求变化会在层级之间反复翻译。

例如“文件分享”不是一个按钮或一个接口，而是包含资源、权限、链接、有效期、访问者和审计的完整能力。产品与技术都应围绕这些概念讨论。

我会先写领域事实，再讨论页面：

type ShareLink = {
  id: string;
  resourceId: string;
  createdBy: string;
  status: "active" | "revoked" | "expired";
  expiresAt?: string;
  access: "anyone" | "organization" | "invited";
  version: number;
};

产品看到的是创建、复制、撤销和访问记录；服务端看到的是状态转换、权限与审计；前端看到的是每个状态下可用动作。三方共享 ShareLink 这组事实，页面和接口只是不同投影。

共享领域语言

先建立关键对象、状态和用户任务，再映射页面与服务。产品确认用户能做什么，技术确认规则由谁拥有，设计确认状态如何被理解。一个词在不同角色那里不能代表三种东西。

状态图尤其有效。它让“审核中能否取消”“过期后是否恢复”这类边界提前出现，而不是等接口联调时才决定。

draft ──publish──> active ──revoke──> revoked
                       └──time──> expired
 
revoked / expired 不直接回到 active；需要创建新版本链接

“恢复过期链接”听起来是一个按钮，实际会影响访问者已经保存的 URL、审计记录和权限预期。决定创建新版本后，前端文案、API 和数据模型同时得到约束，不会各自补一套含义。

路线图也是风险图

功能排期之外，还要看到公共模型、数据迁移和外部依赖的技术风险。有些基础能力不能直接展示，却决定后续多个功能能否稳定交付。

技术也不能用“架构升级”作为脱离产品的独立目标。每项投入应对应降低的风险、减少的交付成本或新增的产品能力。

让边界进入验收

共享地图最终需要转成可验证结果。一个状态由谁创建、哪些角色能推进、失败后是否可恢复，都应成为验收条件，而不只检查正常路径页面是否完成。技术测试与产品验收由此围绕同一组事实。

针对分享能力，验收不只写“可以复制链接”，而会覆盖：

这些场景会自然带出缓存、时钟、幂等和审计问题。共享问题地图的价值，就是让产品边界在写代码前进入工程讨论。

当需求变化时，也先修改地图和状态约束，再评估页面与服务受到的影响。这样变更不会只停留在某一张设计稿，遗漏的数据迁移、通知和权限能更早出现。

当产品和技术共享同一张问题地图，架构不再是后台工作，需求也不再只是页面列表。团队讨论的是同一个系统，只是从不同角度观察。

图：产品与技术使用同一组约束，架构才不会各说各话。

这张地图需要被维护，否则三个月后就变成没人看的旧图纸。我维护它的方式是：每个用户任务连接到产品规则、数据实体、服务边界、SLO 和负责人；箭头写清同步、异步与失败恢复。需求变化时先改地图，再判断影响哪些契约和指标。

地图只保留决定边界的事实，不画每个类。它在产品评审、架构评审和事故复盘中使用，没人使用的图两个月后就删除。共享的价值来自共同决策，不来自图本身复杂。

跨市场产品让这个问题更明显：每个区域的支付、合规和弱网约束都必须进同一张图，否则“国际化”就成了前端文案的事。我在海外 ToC 产品中的前端不是一个页面层里用区域发布矩阵把这张图具体化了。