Appearance
信贷核心系统群架构总览
金融信贷域 · 架构方案层首篇（纲领篇）。上承业务知识三篇：
- 信贷业务全景与领域模型：已按"谁的不变量谁守护"切出五个限界上下文。
- 账务系统设计-复式记账与日切：给出资金事实源的内部构造。
- 风控决策架构：给出决策链路的性能约束。
本文回答再往下一层的问题：上下文为什么长成这些系统。横切能力为什么独立成系统。系统群怎么分三步演进。 行业双样本实践（内部资料，已移除公开库）作为架构决策的对照锚点。方法论挂钩康威定律与团队拓扑、复杂度治理与技术决策与ADR。
一、从业务到系统：五个上下文如何长成系统群
推导的前半段在业务知识篇已完成。额度（三分守恒）、支用/借据（状态机）、账务（借贷必相等）、还款（冲抵顺序）、催收（案件生命周期）五个上下文。边界判据是"谁的不变量谁守护"。后半段是本文要论证的：上下文不天然等于系统。DDD 切的是模型边界，系统切的是进程、数据与发布边界。中间的桥梁是领域事件：
- 事件是上下文之间唯一的合法契约。业务全景篇给出主链路四个事件（授信生效/支用成功/还款成功/逾期切换）的接力。边界两侧只走事件与防腐层、不做跨上下文大事务。这意味着每个上下文的写入路径自洽（分录+凭证同库同事务、借据 CAS、额度条件更新在本域内闭合）。它具备独立部署、独立持库的资格；
- 契约收敛在四个事件上，比收敛在几十个同步接口上便宜。事件 schema 是对外契约（单向门，发布即收不回），数量越少、语义越稳，系统边界的寿命越长；
- 团队认知负荷封顶。上下文即系统即团队：一个流团队装下一个域（领域负荷+系统负荷）。跨上下文需求天然走事件异步协作。"一个需求要三个团队联调"是边界切错的信号（康威定律开始收税）。
由此得到系统群拓扑。同步主干（用户在等的链路）与异步事实分发（事件总线）分两层画：
渠道入口（App / 开放平台 / 联合贷资方入口）
│ 进件KYC │ 支用申请(同步链路) │ 还款指令
▼ ▼ ▼
┌───────────┐ ┌───────────────────┐ ┌───────────┐
│ 客户/进件 │ │ 支用/借据系统 │◀────│ 还款系统 │
│ 客户号·KYC │ │ 借据状态机·放款两阶段 │ 冲抵 │ 冲抵顺序守护 │
└───────────┘ └──┬─────────────┬──┘ └─────┬─────┘
│同步决策 │ 支用成功/还款成功事件（总线,异步）
▼ └───────┬──────────┼──────────┬─────────┐
┌──────────────────┐ ▼ ▼ ▼ ▼
│ 风控决策平台 │ ┌─────────┐ ┌────────┐ ┌──────┐ ┌─────────┐
│ 规则/模型/策略编排 │授信 │ 额度系统 │ │ 账务系统 │ │ 催收 │ │清结算/资方│
│ 名单库/在线特征点查 │────▶│三分守恒CAS│ │复式记账· │ └──────┘ │文件批次· │
└──────────────────┘生效 └─────────┘ │唯一资金 │ │清分指令 │──▶ 资方/渠道
│事实源 │ └─────────┘
└────────┘
═════════════════ 横切层（不属于任何业务上下文，见第二节）═════════════════
幂等与对账中心：订阅全量资金事件 + 渠道/资方对账文件 → 差异工单（只读、不修数据）
数据平台：事件流全量落地 → 日终批（计息核对/试算/监管报表）· 离线特征与变量工厂逐系统的边界论证表（不变量全部承自业务知识篇，此处补"系统化"后的进出契约）：
| 系统 | 守护的不变量 | 订阅 | 发布 | 边界外（绝不做） |
|---|---|---|---|---|
| 额度 | used+frozen ≤ total，且三者 ≥ 0 | 授信生效、还款成功、放款确认/失败 | 额度冻结/解冻/释放 | 不知道借据长什么样，只看到 frozen/used 增减 |
| 支用/借据 | 借据状态机单向迁移，全部 CAS | 放款回执、还款冲抵结果 | 支用成功、逾期切换（经日终批） | 不直接记账务分录 |
| 账务 | 凭证级 SUM(借)==SUM(贷)；流水只插不改 | 支用成功、还款成功、逾期切换 | 日切完成、试算结果 | 不理解业务语义——它不知道"借据"是什么 |
| 还款 | 冲抵顺序：费用→罚息→利息→本金；还款 ≤ 应还 | 还款指令、渠道回执 | 还款成功 | 不动额度、不记分录、不改借据状态 |
| 催收 | 案件生命周期与分案规则 | 逾期切换 | 催收动作回执、外呼结果 | 不改借据状态（只读借据视图 + 动作外呼） |
注意两个容易画错的边界：
- 其一，还款计划属于借据（业务全景篇已论证）。还款系统守护的是"冲抵的分配规则"而不是计划本身。
- 其二，日终计息批是逾期切换事件的发布方。它物理上跑在数据平台、语义上属于账务——系统落位与领域语义可以分离，事件语义不能。
拓扑图里的"客户/进件"不在五个核心上下文之列，是刻意的。客户与 KYC 是主链路的输入侧（把自然人变成客户号），自身不承载资金不变量。与五个资金上下文的耦合只有"客户号"这一个 ID。所以它可以是相对独立的支撑系统，甚至部分外采，不参与核心边界论证。
系统边界的另一半是组织边界（康威定律：团队有几条沟通线，架构就有几条集成线）。系统群与团队拓扑四型的映射：
| 系统 | 团队类型 | 与其他团队的交互 | 考核要点 |
|---|---|---|---|
| 支用/借据、还款、额度、催收 | 流团队（各一） | 彼此按事件契约协作，与决策平台按便利 | 各域业务指标 + 变更吞吐 |
| 账务 | 流团队（专业纵深最大） | 只进事件、只出对账事实 | 日切成功率、差异率 |
| 风控决策平台 | 复杂子系统团队 | 对流团队提供自服务决策 API | 决策质量、延迟 SLO、策略迭代吞吐 |
| 幂等与对账中心、数据平台 | 平台团队 | 便利（X-as-a-Service） | 差异闭环时效、批处理时效、接入自助率 |
这张表反过来读就是回归测试。如果一个需求要同时改支用、账务和对账中心（比如给借据加一个新费用科目）。说明三者的边界被一次变更横切。要么是事件契约设计漏了扩展点，要么是团队边界画错了。
拓扑图上还有一条看不见的线：同步主干与异步事实分发的分工。以支用为例，一笔支用横跨四个系统。哪些步骤用户在等（同步）、哪些步骤事后生效（异步），必须一次性说死：
| 支用步骤 | 模式 | 预算/时限 | 失败语义 |
|---|---|---|---|
| 额度校验+冻结 | 同步 | <50ms | 冻结失败=拒绝，available 不变 |
| 风控交易决策（决策快照同步落库） | 同步 | <200ms（含上项，见风控决策架构） | 超时按场景降级：授信 fail-close / 支用静态规则兜底 |
| 立借据+放款指令 | 同步 | <500ms | 放款失败=解冻 frozen，借据 CANCELED |
| 账务分录、frozen→used、还款计划通知、数据落地 | 异步事件 | 秒级，对账兜底 | 事件丢失=差异单，不是丢钱 |
这张表就是 ADR-002 的雏形：同步段的每一步都产出"可回退的中间态"（frozen、决策快照、借据 CAS）。异步段只消费"已成立的事实"。支用链路的可靠性设计，一半在做状态设计，一半在做事件设计。
二、横切关注点的系统落位
三个横切能力必须独立成系统，而不是做成业务系统里的"公共模块"。独立的判据有三条——延迟预算不同、变更节奏不同、所属团队类型不同。三者任一成立就有独立部署资格，三条全成立就没有讨论余地：
幂等与对账中心——裁判独立。 对账要抓的错包括业务系统漏发事件、账务记了半边分录。让任何业务方"自查自对"等于既当运动员又当裁判。它独立的三条理由：
- 输入是全量资金事件 + 渠道/资方对账文件，输出是差异工单。只读、只产差异单、永不修数据。这个纪律只有在独立系统里才能强制执行（承幂等与对账-资金安全底座）；
- 它的权威来自对所有系统一视同仁。挂在账务里就失去对账务的裁判权，挂在业务里就失去对业务的裁判权；
- 差异的资金侧统一在账务处理（挂账科目/红冲），过程侧统一在对账中心处理（差异工单闭环）。两个系统一个管"账平"，一个管"发现为什么不平"。
风控决策平台——频率与预算独立。 三重不同构：
- 延迟预算不同构：支用交易决策 P99 < 200 ms 且同步串联在支付链路里。它与业务系统的秒级预算差一个量级。独立部署才谈得上独立容量规划与独立降级（fail-close / 静态规则兜底的预案自动化只属于它）；
- 变更节奏不同构：策略一年改几百次、热更新+灰度发布，信贷主系统周级发布。合在一起等于每次调策略都是信贷发版，每次发版都是事故窗口；
- 团队类型不同构：算法工程师+策略分析师是典型的复杂子系统团队。它与信贷流团队按"便利（X-as-a-Service）"模式交互。决策平台是自服务产品，不是按需求排队的兄弟部门（团队拓扑三交互模式）。
数据平台——批量与智能独立。 日终批逐借据计息、全表试算、四层核对，在亿级借据下是 T 级扫描。它不能与联机交易抢同一套库。双样本在这一点上路径不同、答案相同。样本银行A把日终批搬上 DaaS（日离线 200T+）。样本银行B把批量从 TDSQL 卸载到 TiDB（联机批量解耦）。
在线/离线的切分线画在：在线特征点查（P99 < 50 ms）留在决策平台延迟预算内。离线特征工厂与变量服务归数据平台。两者以"同一份特征定义"对齐（线上线下一致性是特征平台第一难题，见风控决策架构）。
代价照实记：独立系统是复杂度转移——把复杂度从业务代码转移到专职平台，前提是有专职团队养。每个横切系统的立项书必须回答"三年后归谁养、替代或合并了什么"。三个系统的边界汇总成一张表：
| 横切系统 | 边界内（只做） | 边界外（不做） | 独立性判据 |
|---|---|---|---|
| 幂等与对账中心 | 事件/文件勾对、差异工单闭环、准实时止血 | 修任何数据、持有资金科目（挂账在账务） | 裁判独立：对所有人一视同仁 |
| 风控决策平台 | 规则/模型/编排/名单/在线特征、降级预案自动化 | 改额度（只产出决策，额度变更归额度系统）、碰资金 | 预算+变更频率+团队类型三重不同构 |
| 数据平台 | 事件流落地、日终批、离线特征/变量、监管报表 | 参与在线决策链路（在线点查归决策平台预算内） | 联机批量解耦：批量不与交易抢库 |
一个高频落位反例：把"幂等"做成业务系统引注的公共库（注解+去重表）。同时把"对账"留在各系统自己的定时任务里。前者合理（幂等三层的第一层本就该是 SDK），后者是把裁判下放给运动员。幂等可以是库，对账必须是系统。库解决单笔正确（代码问题），系统解决存量正确（组织问题）。幂等与对账篇里它们同属资金安全底座，落位却是两个东西。
三、双样本架构参照：业务动因决定架构形态
样本银行A与样本银行B是同一份信贷领域模型的两个镜像实现。几乎所有分叉点都能追溯到出资结构与获客方式的业务差异。对照表（事实带可信度标注，架构解读为本文推断）：
| 对照维度 | 样本银行A（A系生态） | 样本银行B（B系生态） | 业务动因 → 架构决策 |
|---|---|---|---|
| 出资/产品结构 | 310 自营闭环：自营出资、场景主动进件（码商/农户）、0 人工 | 联合贷：样本银行B出风控+部分出资，数百家合作银行出资（新规 ≥30%） | 出资结构决定信息流复杂度：单主体记账 vs 每张借据出厂即按资方份额拆分——额度占用/借据/账务/清分从第一天就多主体化（清结算与资方对接） |
| 单元化与分片 | 三地五中心：RZone 分片 + GZone/CZone，每分片 OceanBase 5 副本 Paxos（RPO=0、RTO<1min） | DCN 按客户号分片 + Openhive，DCN 级双活 | 共同决策、不同实现：分片键=事务边界，凭证级借贷断言在分片内本地成立，不退化为跨分片分布式事务 |
| 账务底座 | OceanBase 分布式强一致（一代核心承袭 SOFAStack/XTS） | TDSQL 联机（800+ 节点）+ TiDB 批量卸载（日终批 3h → 目标 0.5h） | 分布式不改数学不变量：SUM(借)==SUM(贷) 在写入路径上成立；联机批量解耦是共同答案 |
| 获客与风控位置 | 风控在授信内：数据源创新（大山雀遥感/百灵凭证 CV）撑 3 分钟进件 1 秒放款 | 风控在产品前：白名单邀请制，"谁能看到入口"本身就是第一道风控 | 风控位置决定进件系统形态：进件是数据采集器 vs 名单分发器 |
| 对账外圈 | 机构侧：代销 23 家理财子（布谷鸟），多机构账单勾对是日常形态 | 资方侧：数百家合作银行按出资份额分账对账，N+2 方勾对 | 外圈的复杂度方向由合作模式决定：代销向外勾对机构，联合贷向内拆份额 |
| 组织形态 | 信息科技部条线制（微服务拆分维度公开披露含"组织结构"） | 四大事业群 + 科技产品部落制（贷款科技产品部） | 康威定律双向成立：组织复制进架构，也按目标架构反塑（逆康威） |
三条结论：
- 没有更先进，只有更匹配。把样本银行B的多资方清分复杂度搬给样本银行A是纯浪费（它没有资方）。把样本银行A的三地五中心塞给早期样本银行B是过度设计。引用双样本时必须带上业务动因，否则就是背图；
- 双样本的收敛处接近行业不变式，可作为本域默认项。默认项：联机批量解耦、凭证级断言留在分片内、幂等三层+对账兜底。以及"账务的 unavailable 是事故，wrong 是灾难"。收敛处的默认也要写 ADR——默认决策没有记录，三年后没人知道它是选出来的还是碰巧的；
- 分叉处回到自己的业务动因再选。出资结构（自营 or 联合贷）、获客形态（场景进件 or 白名单）、数据基因（交易 vs 流量）。这三问答完，架构形态基本自动确定。
四、演进路线：三阶段与触发信号
为什么恰好是三阶段：它们分别对应三根轴的刻度。业务成熟度（要不要验证）、组织规模（一个团队装不装得下）、监管与资金规模（容灾目标是什么）。三根轴各自独立推进，架构只取三者的短板向上取整。
阶段一 MVP（0→1，验证业务）
┌───────────────────────────────────────────────────┐
│ 信贷单体（模块化） │
│ ┌────┐ ┌────┐ ┌─────┐ ┌────┐ ┌────┐ │
│ │额度 │ │支用 │ │账务 │ │还款 │ │催收 │ ← 模块边界 = │
│ └────┘ └────┘ └─────┘ └────┘ └────┘ 未来系统边界 │
└──────────────┬─────────────────────┬───────────────┘
│ 外采 │ 嵌入式规则引擎起步
▼ ▼
催收外包/外采坐席系统 风控决策(规则+人工)
阶段二 分域微服务（业务成立，组织扩张）
┌───────┐ ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐
│ 额度 │ │ 支用/借据 │ │ 账务 │ │ 还款 │ │ 催收 │ 各自持库·各自发布
└───┬───┘ └────┬────┘ └───┬───┘ └───┬───┘ └───┬───┘
└──────────┴─ 领域事件总线 + 幂等与对账中心(独立) ─┘
风控决策平台独立化 · 日终批迁数据平台 · 账务外采转自研或深耕
阶段三 单元化多活（规模与容灾要求）
客户号分片 ─▶ 单元(RZone/DCN)内闭环 ─▶ 单元级双活 ─▶ 多地
分片键=事务边界 · 日终批完全卸载批处理平台 · 单元级切流演练常态化跃迁不是日历驱动而是信号驱动——出现以下信号才启动，启动到完成以年计：
| 跃迁 | 触发信号 | 判据来源 |
|---|---|---|
| MVP → 分域微服务 | ① 一个普通需求要 >2 个团队联调排期（康威收税的量化判据）；② 单体发布互相阻塞、发布频率持续衰减；③ 外采系统与主系统数据打架、对账差异率压不下来；④ 某个域的变更热点显著集中，单体发布把全域绑上 | 康威定律、复杂度代理指标四件套 |
| 分域 → 单元化多活 | ① 单库容量/连接数/热点行到顶，垂直扩容治标失效；② 容灾目标升级：RPO=0 / RTO<1min 成为监管或资金规模的要求；③ 峰值为日常十倍成为常态，全链路压测显示单单元无法承载 | 容量规划、多活容灾与单元化 |
| 逆向信号（该合并） | 五个系统的需求长期由同一团队提出；某系统 90 天流量为零且无独占团队——按复杂度治理走合并/下线/代管 | "每季度砍一个系统"减法清单 |
信号自己不会响：三类跃迁信号（含逆向信号）都应进季度架构治理会的常设议程。它们与复杂度代理指标同堂过堂——没进议程的信号等于不存在。
两条阶段纪律：
- 阶段一的核心资产是边界不是代码。模块间只走事件/接口（与未来系统间协议同构），数据库按上下文分 schema。微服务化时迁移的是部署形态，不是重新设计边界。边界没守住的单体，拆微服务等于把泥球切成五个泥球；
- 拆的前提是平台能力承接（复杂度转移定律）。没有事件总线的运维能力和对账团队之前，拆出去的协调复杂度比留在单体里更贵。团队拓扑上，先有平台团队（事件总线、发布、观测），再拆流团队。
三个常见的误判也值得钉住：
- 把"业务成功"当跃迁信号：量涨了不等于要单元化。先看单库水位与容灾要求。单元化是规模与监管驱动的决策，不是融资进度的函数；
- 跳阶段：没有分域微服务阶段的事件与对账积累，直接上多活。这等于把"账有延迟"的风险直接放到异地副本上——多活放大的不是能力，是没还的债；
- 把外采当永久态：MVP 的外采系统（催收/坐席）要写明退出条件（数据模型冲突、差异率、定制排队时长）。没有退出条件的外采会在阶段二变成最难拆的边界。
五、关键架构决策记录（ADR 摘编）
五个上下文系统化、三个横切独立，一路上有几十个决策点。够格进 ADR 的是单向门——改一次动几年数据与上下游的那种（可逆性判断见技术决策与ADR）。金额精度、计息口径、分片键同样是单向门。但它们属于系统设计层的决策细节，留给系统设计与模块设计层记录。本文摘编三个决定系统群形态的，按模板缩写、重点保留"放弃的选项与代价"。
ADR-001 账务独立系统，不嵌入信贷主服务（状态：已接受 · 2026-10）
- 背景：账务是全公司唯一资金事实源（复式记账不变量 + 流水只插 + 四层核对）。嵌入信贷主服务会让"业务视角的账"与"会计视角的账"混进同一个模型。科目演进被借据表结构绑架；
- 决策：账务独立成系统，只认分录不认业务语义。它不知道"借据"，只知道科目账户上的一组分录。业务事件经防腐层翻译为记账指令；
- 后果：正面——业务中立使它可承载任何未来产品（分期/票据/供应链）。凭证级断言与日切拥有独立发布与容量。代价——每个新产品新增科目要过账务评审（协调成本）。事件丢失即漏记，必须配对账兜底；
- 放弃的选项：嵌入主服务、与借据同库同事务"看似省事"。账务表与借据表耦合后，任何产品改动都可能碰到总账，且账务无法复用到非信贷业务。这一选项在微服务化时将被迫返工，返工成本远高于独立成本。
ADR-002 支用链路：同步做决策与占额，消息做事实分发（状态：已接受 · 2026-10）
- 背景：支用是用户在线等待的操作（极限样本：310 授信 1 秒放款）。但它横跨额度冻结、风控决策、立借据、放款出账四个系统步骤。全同步还是全异步必须二选一；
- 决策：用户在等的正确性链路同步串联（额度校验冻结 → 风控交易决策 → 立借据 → 放款指令）。延迟预算硬分解（决策段 P99 < 200 ms）。放款成功之后的事实分发（账务分录、额度 frozen→used、通知、数据落地）全部走领域事件异步；
- 后果：正面——每一步失败语义清晰（冻结失败=拒绝，放款失败=解冻）。体验与资金安全解耦。代价——事件丢失存在"钱出去了、账没记"的窗口。靠本地事件表（先落库后发布）+ 准实时对账补单兜住。消费侧幂等成为全链路纪律；
- 放弃的选项：全同步大事务（TCC/XA 包整链）。它把账务 DB 锁延伸到所有业务方，吞吐与可用性不可接受（刚性/柔性事务取舍）。全消息驱动——额度冻结与风控决策的应答本身就是支用的业务结果。异步化等于让用户为结果排队。折中方案（决策同步、冻结异步预占+事后核对）同样被否。决策通过到冻结确认之间的超卖窗口没有天花板，与 ADR-003 的资损不变量直接矛盾。
ADR-003 额度一致性：行内强一致，跨上下文最终一致（状态：已接受 · 2026-10）
- 背景：used+frozen ≤ total 是资损不变量（超扣=无上限敞口，少扣=客诉）。但额度变更来自四个方向（授信/支用/还款/调额），不可能用一个事务圈住所有来源；
- 决策：额度行每次变更走 DB 条件更新（
WHERE total-used-frozen >= X），行锁串行化热点，行内强一致。跨上下文（如还款成功→额度释放）走事件最终一致 + 对账兜底； - 后果：正面——资损不变量在写入路径上数学成立，不依赖上层代码自觉。代价——热点客户并发支用在同一行排队（需预热散热/限流）。available 是推导值、任何旁路直改都违宪，需要 CI 巡检兜住；
- 放弃的选项：分布式锁包额度域——锁服务故障即全站不能借钱，可用性比行锁更差。额度全链路最终一致——超卖敞口没有天花板且资损不可回退，属于把单向门当双向门过。
三个 ADR 的公共结构：不变量落在写入路径的数学里（CAS/断言）。协作落在事件与对账里。代价全部是"协调成本"而不是"正确性"。这是资金系统决策与一般业务系统决策的分水岭。
六、追问链
Q1：五个上下文为什么不直接拆五个微服务？MVP 阶段合住一个单体行不行？
行，而且推荐。上下文边界先于系统边界成立。模块化单体里按上下文分模块、分 schema，事件协议照发（进程内事件）。微服务化时迁部署形态、不重画边界。直接拆的时机由第四节触发信号决定；没有平台团队就拆，是复杂度治理里的负分决策。
Q2：事件总线挂了，信贷不是全停？ 不是。用户动作的同步段（冻结/决策/立借据/放款指令）是同步 RPC，不依赖总线；总线只承载事实分发。总线故障的表现是"账有延迟"而非"钱有差错"。本地事件表保证事件不丢（先落库后发布）。准实时对账把延迟显形为差异单而不是用户客诉。
Q3：对账中心为什么不能并进账务系统？它天天和账务打交道。 对账要抓的错包括账务自己的（试算平衡抓单边分录、账账核对抓总分脱节）。并进去等于让账务自查自纠。而且对账要勾对业务/账务/渠道三方，放进任何一方都会失去对另外两方的裁判权。独立 + 只读 + 只产差异单，是它敢指出所有系统错误的前提。
Q4：单元化的分片键为什么是客户号而不是借据号？
分片键=事务边界。同一客户的额度行、借据、还款在一个单元内闭合。额度 CAS 与借据状态机是同客户高频并发的写冲突方。拆到两个单元，额度行就变成跨单元强一致问题，回到原地。借据号做二级索引即可，不做路由键。这个判据可以推广成分片键选择的通用公式：把全系统最高频的写冲突对，圈进同一个分片。
Q5：双样本都这么强，照抄谁的？
都不抄，抄收敛处。联机批量解耦、凭证级断言留在分片内、幂等三层+对账兜底——两家以不同路径验证过的行业不变式。直接作为默认项。分叉处（自营 vs 联合贷、OceanBase vs TDSQL+TiDB、条线制 vs 产品部落制）。回到自己的出资结构、获客形态与组织现状再选。引用时事实带可信度标注，解读与事实分开说。
Q6：账务外采（套账系统）还是自研？
看出资结构再答：单主体自营（样本银行A形态）的业务中立账务。外采套账常因科目模型对不上互联网产品形态（分期/权益/营销补贴的分录）而格格不入。且日切核对要和自研事件链路深度耦合。倾向自研核心+外采报表。
多主体联合贷（样本银行B形态）的清分/资方对账层几乎必然自研。因为没有任何外采产品出厂就懂"数百个资方按监管版本分账"。判据还是那条：这层系统承载的是行业通用语义（可外采）还是自己的业务动因（必自研）。
Q7：本文和 C-架构 的平台无关方法论（分布式事务/多活/ADR）是什么关系？ 分层引用而非复制：C 轨回答"这个技术为什么成立"（刚性/柔性事务取舍、RZone/DCN 机制、ADR 模板）。本文回答"信贷域为什么选它、选到什么程度"。同一份单元化，C 轨讲机制。本文第三节讲双样本为什么各自选了不同实现、第四节讲你什么时候才需要。业务耦合的方案放本域，平台无关的场景放 C 轨，通过互链挂钩而非复制（本层 README 的分工约定）。
面试官视角小结
- 考"从业务推系统"：能否说清每个系统边界背后是哪条不变量、哪几个事件契约。只会画框图说"解耦"的是背图，说得出"账务不知道借据是什么"的才是推过；
- 考横切落位：对账中心/风控/数据平台为什么独立是高频题。锚定三判据（延迟预算、变更节奏、团队类型）比背"中台"名词有效；
- 考演进判断：说出阶段触发信号（组织、容量、监管三类信号）比背三阶段图重要。主动提"逆向合并信号"是加分项——只讲拆不讲合的演进叙事不完整；
- 考决策素养：三个 ADR 都要能答出"放弃的选项+代价"。只说优点的是宣传稿，说得出"为什么不是 TCC"的才做过取舍；
- 考引用纪律：双样本事实带 [官方]/[媒体] 可信度标注，自己的推断单独声明。面试与写文档是同一种诚实；
- 考协议演进：四个领域事件的 schema 怎么兼容变更（加字段/升级语义），是系统群落地后的第一道长期题。对应《系统设计如何全方位考虑兼容性问题》的四层检查。
一句总纲收束全篇：业务动因是第一因。出资结构与获客形态决定上下文，上下文与事件契约决定系统边界。团队认知负荷决定边界落成几个系统。横切按判据独立，演进按信号迈步，单向门决策留 ADR。 后续篇目（账务平台、决策平台、多资方接入、数据平台）都是这四个句子在某一个边界内部的展开。
2026-10 新增（金融信贷域 · 架构方案层首篇）。 姊妹篇：
- 业务知识/信贷业务全景与领域模型（领域模型与事件接力）。
- 业务知识/账务系统设计-复式记账与日切（资金事实源）。
- 业务知识/风控决策架构（决策链路）。 行业对照样本详见内部资料（已移除公开库）。本层后续篇目见 README。