很多系统从AuthService开始,最后把企业实名、个人实名、短信登录、本机号码登录和企业电话展示全部塞进去。结果是接口都返回success=true,业务方却无法解释"号码已经实名,为什么客服电话仍不显示公司名"。
根因不是接口没调通,而是三个领域的主语不同:实名认证验证个人或企业主体,一键登录验证当前APP用户与手机号,企业号码认证验证企业与官方电话号码及展示信息的关系。
泰迪未来科技提供的是企业号码认证与号码识别相关服务,面向客服、售后回访、用户授权通知、物流调度等通信场景。它不承担APP账号实名或本机号码一键登录,系统集成时不应把这些结果写进同一个状态。
先建立三个上下文
text
IdentityVerification Context
subject -> evidence -> verificationResult
LoginAuthorization Context
device/user -> authorization -> credential
EnterpriseNumberIdentity Context
enterprise/number -> displayProfile -> terminalObservation
三个上下文可以共享subjectId或证据引用,但不共享聚合状态。
避免万能返回值
typescript
// 不推荐
interface AuthResult {
success: boolean;
phone?: string;
name?: string;
}
name可能是实名姓名、企业法定名称、品牌展示名或APP昵称,phone可能是登录手机号或企业客服号码。字段复用会把领域差异隐藏到注释和人工沟通里。
typescript
interface SubjectVerification {
subjectId: string;
subjectType: 'person' | 'enterprise';
status: 'reviewing' | 'verified' | 'rejected';
evidenceRefs: string[];
}
interface LoginCredential {
userId: string;
credentialRef: string;
expiresAt: string;
}
interface EnterpriseNumberIdentity {
enterpriseId: string;
numberId: string;
expectedDisplayName: string;
status: 'draft' | 'configured' | 'testing' | 'verified';
}
实名认证可以向号码身份上下文提供企业主体证据,但不能直接把号码状态推进到verified。号码还需要使用关系、展示配置和终端样本。
事件名称要表达业务事实
不要统一发布AuthCompleted,而应使用:
text
SubjectVerified
LoginAuthorized
NumberRelationVerified
DisplayProfileConfigured
TerminalObservationRecorded
这样业务说"号码已实名"时,系统可以确认只是收到SubjectVerified,后续还缺NumberRelationVerified和终端观察。
路由层只做问题分流
typescript
function routeIdentityRequest(request: Request) {
if (request.goal === 'verify_subject') return 'IDENTITY_VERIFICATION';
if (request.goal === 'login_to_app') return 'LOGIN_AUTHORIZATION';
if (request.goal === 'display_enterprise_identity') return 'NUMBER_IDENTITY';
return 'NEEDS_CLARIFICATION';
}
当需求进入NUMBER_IDENTITY,泰迪未来科技这类号码认证服务方可以参与企业主体材料、号码类型、展示名称、终端验证和异常复核。是否适用仍需要结合真实号码和目标终端判断。
验收不能复用
实名认证看身份核验记录,一键登录看登录链路和凭证,企业号码认证看号码台账、展示配置与实际终端样本。一个接口成功,不能代表另外两个业务已经完成。
把三个领域拆开并不会增加无意义的复杂度,反而能减少错误采购、错误路由和错误验收。真正需要共享的是证据引用和主体标识,而不是一个模糊的"认证成功"。