MemoFlow · Account 领域模型开发笔记

按版本记录 Account 从核心聚合到 Auth、Setting、Notification 与本地 Profile 权限分离。

#blog #growing #dev

Account 模块目标

我想把 Account 的领域模型重新整理一下。现在的 Account 类包含用户名、邮箱、认证状态、个人资料、偏好、订阅、统计和审计信息，字段越来越多；继续加功能，很容易变成一个什么都管的巨大对象。

目标是先明确 Account 的核心数据，再判断哪些信息应该作为实体扩展，哪些应该交给独立模块。

第一版先沿着 DDD 聚合根 + 扩展实体的思路设计。

Account 聚合根保存稳定标识、用户名、状态和必要时间信息；Profile、Subscription、History 等拆成有明确职责的对象。这样既能在 Account 内统一校验核心规则，又不必把所有字段直接塞进一个类。

新增需求时，例如个人资料或将来的企业资料，可以根据它们的业务关系选择扩展实体。这个方案比将所有字段直接平铺到 Account 上更容易维护。

但需要注意：能写成 Account 的一个子对象，不意味着它一定应该由 Account 持有。 如果一个业务有自己的生命周期和一致性要求，强行放入同一个聚合反而会让边界变大。

现在先把账号资料与认证分开。

邮箱、密码、登录验证和 Session 与昵称、头像、简介不是同一种事实。即使它们显示在同一个“账号设置”页面，也不应该靠一个 Account 保存所有认证信息。

所以 Authentication 负责验证用户身份和管理会话，Account 负责产品资料。业务通过稳定的 Identity 关联它们，而不是把认证服务当作 Account 的几个可随意修改的字段。

审计信息同样要注意：它记录变化和操作来源，但不一定需要让一个巨大 Account 聚合每次都加载完整历史。

在更多业务模块接入之后，边界还需要更明确：

这版决定以谁拥有数据真值与业务规则来划分，而不是以页面分类来划分。跨模块组合显示可以用 Read Model，不需要把相邻模块的数据复制成 Account 的可写字段。

例如用户修改邮箱，应执行 Cloud Auth 的流程；普通 Account 资料更新不能顺便篡改登录凭据。

现在要处理离线 Desktop 与云端 Account 的联系。Guest 可以有真实的本地 Profile 和产品资料，云端 Account 则与 Better Auth 身份绑定；两者不应因为某次登录而变成同一个对象。

用户连接云端时可以保留本地 Profile、Vault 和本地资料，之后再以明确的绑定与同步流程协调数据。关闭云端账号也不自动删除本地 Profile。

数据导出同样只应包含用户自己拥有的资料字段，不能把 Session、认证密钥或 Account 生命周期偷偷塞进可移植资料。这样扩展 Account 功能时，不会再让“与用户有关”成为无限扩大聚合边界的理由。