TOGAF与DDD融合实践——某城商行「纾困贷」案例深度剖析

大是大非——应用架构方法思想

【思想1】应用架构必须对齐业务战略与流程（而不是IT导向的应用架构设计）

应用架构的源头和最终评判标准是业务，而非技术本身。设计起点必须是“业务要解决什么问题”（如纾困贷的商业模式、管控要求），并通过业务流程（L3-L5）将业务需求具象化，确保每个应用组件的存在都能在业务战略和流程中找到直接依据。这避免了技术驱动的“为了架构而架构”，保证了IT投资的有效性。

【思想2】管控/外部/内部多视角业务架构分析（而不是只关注商业模式）

全面理解业务不能只看如何赚钱（商业模式）。必须同时分析外部价值创造（商业模式）、管控合规要求（管控模式）和内部协同效率（业务模式）。这种多视角分析确保了应用架构既能支持业务创新，又能内嵌风险控制，还能优化内部协作，避免了因视角单一而产生的设计漏洞。

【思想3】业务流程作为DDD分析的正规驱动（而不是随意的访谈与事件风暴）

领域驱动设计（DDD）中的事件风暴和领域建模不是凭空进行的，其输入应是已经过梳理和确认的、结构化的业务流程（如案例中的L5流程表格）。流程中的每个步骤、参与者和数据流，为识别领域事件、聚合根和界限上下文提供了客观、可靠的输入，确保了领域模型与业务运作现实的高度一致，减少了主观偏差。

最佳实践——应用架构实践技巧

【实践1】结构化业务需求定义（而不是单薄的客户旅程+用户故事）

采用 “stream 视图（价值流）、chain 视图（价值链）、业务流程图等多维度视图刻画业务架构，确保设计全面性与可读性，展示业务端到端的价值传递路径。不尽如此，还要通过 “上渠道、中业务、下支持、右接口” 框架，明确前端（APP、Web 门户）、核心业务（贷发放、贷后管）、外部集成（人行征信、政府政务）等多维度需求，使需求定义更全面立体。

【实践2】利用DDD数据聚合优点启发应用划分（确保应用业务解耦）

在应用划分过程中，应充分利用DDD数据聚合的优点，确保应用之间的业务解耦。案例中，基于 DDD 识别的领域对象（如贷款状态、贴息申请单、整改通知）及领域子域，将架构划分为对公贷款服务、贷后监控、贴息管理、逾期处置等逻辑应用组件，每个组件对应独立数据聚合与业务域，避免业务交叉耦合。

【实践3】通过应用架构GAP分析识别项目（明确迭代实施路径）

理想的目标应用架构与当前现状之间必然存在差距。GAP分析就是系统性地对比“未来态”和“当前态”，清晰识别出需要新建、重构、集成或淘汰的具体应用项目。这将宏伟的架构蓝图转化为一份可执行、可优先级排序的项目清单，为分阶段、分迭代的敏捷实施提供了清晰的路线图，保证了架构的平稳落地。

【1】战略溯源——职能战略条目化与变化分析

领域解决方案设计，本质上是从【L3流程】对接整个BA的：

l 职能战略往往是【方案】立项的根本，必须呼应

l 还要在过程/产物/标号上，与BA L1 L2流程呼应

【2】模式分析——商业模式/管控模式/业务模式及变化分析

商业模式——内外拉通：扬长避短服务客户，赚到钱

管控模式——上下拉通：上级机构如何监管，保合规

业务模式——前后拉通：职能联动流程通达，促效率

业务模式，如下：

管控模式，如下：

【3】领域级BA——【纾困贷】L3-L5 BA架构（stream视图）

价值流视图

价值流视图

【4.1】领域级BA——【纾困贷】L3-L5 BA架构（chain视图）

价值链视图

【4.2】领域级BA——领域方案需求与约束（业务需求、渠道需求、集成需求）

用【上渠道、中业务、下支持、右接口】画图

【4.3】领域级BA——【纾困贷】L3-L5业务流程

【5.1】L5驱动的DDD——领域对象识别、事件风暴分析

【5.2】L5驱动的DDD——领域子域划分、逻辑应用识别

【6.1】领域应用架构——逻辑应用划分（框图风格、组件图风格）

【逻辑应用组件】

l 前端逻辑组件 列出【前端程序】

l 后台逻辑组件 列出【逻辑应用】

l 平台逻辑组件 列出【逻辑应用组件】

l 基 础 设 施 少量【三方框架】

【6.2】领域应用架构——应用架构GAP分析（识别应用项目）