金融风控领域的 DDD 与中台思考

风控领域作为金融核心领域之一，对金融业务发展有着至关重要的作用。风控直译就是风险控制，其核心是对风险与成本的平衡。风控业务开展离不开风控系统的支持，本文就风控系统如何规划架构与演进，以及对领域驱动设计的思想和风控中台战略的思考。

风控与 DDD

领域驱动设计（DDD）作为微服务拆分的指导思想随着微服务化火起来，但其过于抽象难懂，网上方法论众多，而案例较少。本文尝试对风控领域如何按 DDD 思想设计给出一些实践和思考。

DDD 从需求分析出发进行领域建模，先划分出多个问题域和子域，再将问题域落实到限界上下文 Context Bounds，并关联成上下文地图，最后运用限界上下文作为微服务拆分的原则，每个限界上下文可拆分成一个服务独立部署，这是 DDD 战略设计部分。

问题域

问题域即为风控领域，问题子域如何划分？从风控发展过程和手段来看。早期风控都要部署各种规则策略，满足反欺诈及合规的硬性要求，那么第一个核心子域应该就是规则。而规则实施离不开数据和特征/指标/变量的支持，第二个核心子域即为特征。随着大数据技术和人工智能技术的普及，智能风控中模型成为重要手段，那么第三个核心子域就是模型。

接下来以子域为中心进行领域建模，进一步划分出每个领域的限界上下文，这里依据业务领域知识，面向业务变化，关注限界上下文内概念完整性以及高内聚低耦合原则拆解。

规则域

规则领域，是利用传统金融风控的规则、策略、评分卡等手段，通过部署规则策略，组织流程，完成决策输出，按此流程可拆分规则、决策、流程三大部分。

规则是通过模型匹配的方式，满足特定条件给出特定输出动作，限界上下文对应的就是规则引擎系统。参考：规则引擎实现方案

决策是利用规则的结果完成进一步的动作，比如拒绝阻断，进入人审，给出评级评分建议等，其对应的就是决策引擎系统。参考：风控决策实现方案

流程是对规则和决策的编排，按 BPMN 组织成不同的规则流/决策流，并加入分支和 AB 实验，一般也叫流程引擎系统。参考：决策流实现方案

因此有了规则引擎、决策引擎、流程引擎三个系统。由于三个系统相互依存，设计时可合并为一个系统 按模块来划分，业界统称为金融决策引擎系统。规则、决策、流程为该系统的三大核心模块。

模型域

模型领域，从工作流程上包括特征挖掘，数据建模，模型生产预测，模型管理，模型部署， 模型监控等。还有另一维度可以划分成离线部分和在线实时部分，离线部分主要工作侧重数据挖掘和离线训练建模，而实时部分承担了将模型应用生产来做评估。由于离线和实时差别较大，所依赖组件更不相同，这样的划分更合理，将“相同变化”聚合到同一模块中。

领域划分时可以将离线部分统一为机器学习平台，其职责边界为离线特征挖掘、数据建模和模型迭代。将实时在线部分统一为模型引擎系统，承担生产模型打分工作。将离线模型部署到生产、模型版本管理、模型性能监控分析等可以为模型管理后台。

特征上下文可能会横跨模型域和特征域，其中离线特征挖掘工作一般是模型域的工作边界，而实时特征计算则属于特征域的部分。

特征域

特征领域从特征用途上，分为支持规则决策的特征/指标，支持模型打分的特征变量（X 变量）。从来源上，均来自数据加工，数据又可能来自生产系统用户录入、数据采集、三方数据 API。

首先数据部分工作归为数据平台，可再分为外部数据和内部数据，外部数据一般以 API 方式存在，称为外部 API 数据平台。内部数据可以提前加工成特征/指标，需要时直接提取，称为特征平台/指标平台/变量平台（各公司叫法不一）。
 

针对模型用特征和规则用特征，可合二为一，也可拆分独立，二者在维度和数量级上还是会有较大差异。

数据的加工计算和存储方式决定了系统的执行效率，依赖不同技术组件，离线加工计算、实时加工计算、预计算等差异可以衍生不同的系统架构演进。

离线计算一般是批处理即为离线计算平台（基于 Hive/Spark）；实时加工计算一般为实时特征引擎；预计算采用流式计算引擎（Flink）成为流计算引擎平台；图关系特征更适应图数据库成为图关系平台；用户标签会构建为用户画像平台；还有名单系统（黑白灰名单）等不同平台。

划分时控制更细粒度就会有更多系统平台，能保持最少组件依赖和系统单一原则，而有时考虑维护成本和团队规模也会统一整合为特征平台，数据平台这种粗粒度系统限界。

以上拆分是领域驱动设计的战略设计部分，在宏观战略上做出设计，而针对单个服务的战术设计，定义聚合根、实体、值对象则是另一篇内容。

实际系统架构时并不能按理想设计一步到位，而是基于长期业务经验逐步演进和拆分而来。微服务拆分本就各有不同，各成体系，孰优孰劣适合团队、满足业务发展需求更重要，毕竟还有“康威定律”以及“遗留系统”两座大山。

风控中台

中台是前两年流行起来的“救命稻草”，但事实证明也并非银弹，是非曲折暂不论。我理解它更多来自各类业务中普适性的业务逻辑与通用流程的沉淀，是一种跨业务的、全局的能力复用，能快速支持不同业务场景。那么金融风控领域的中台怎么定义呢？

风控领域有着天然的中台培养价值，金融领域大多与金钱打交道，那么风险控制不可避免，各类业务场景无论信贷、消费贷还是信用卡、保险，均存在不同的风险控制环节，在信贷审计、贷中贷后管理、发卡评估、理赔欺诈等应用场景均有风控诉求。那么统一风控中台的搭建收益良多，凡是需要风控的业务都可以快速对接风控中台来满足自己业务的风控目标。

风控中台是将以决策引擎为核心驱动，以模型引擎为大脑，在特征引擎、数据平台的基础上构建的一套通用风控能力。需要对其高度抽象，围绕风控领域展开，并减少不同业务属性的侵入，任何业务场景可快速复用一套中台，符合中台的定位。

那么业务场景的差异如何处理？如信贷审批场景侧重反欺诈和信用评级两方面，信用卡场景侧重评级和额度，保险场景又有不同，依赖的决策流程和结果各不相同。中台决策引擎会根据场景不同匹配执行不同决策流，以 Pipeline 方式组装不同规则、决策、分支，并输出执行过程和决策结果，再通过前台翻译、组装结果满足业务诉求。

风控前台层是风控中台和业务系统的代理和桥梁，也是业务接入层，其为一套系统还是多套系统还看“康威定律”。如果业务接入由各业务线负责维护，那么各自维护一套服务，否则一个团队可以维护一套服务并拆分模块治理。

相对的配置管理后台、监控后台，面向内部策略分析师和业务运营团队，即为后台层。以及数据和计算引擎这类支撑平台。当然数据部分独立成数据中台也是更普遍的做法。

以上是基于个人工作经验的一点思考，如有纰漏敬请谅解，感谢阅读。