DDD、BFF 和 API First 在百度企业应用服务的实践和思考
如果无法正常显示，请先停止浏览器的去广告插件。
1. DDD、BFF 和 API First 在百
度企业应用服务的实践和思考
吕航⻜
百度 爱番番业务部资深架构师
2. 自我介绍
百度爱番番业务部资深架构师，百度DDD布道师，负责爱番番IM和线索管家的技术架构
• 2008-2018 SAP 中小型企业ERP研发经理、架构师
• 2018-2020 小黑⻥科技 基础服务部技术负责人
• 2020-至今 百度爱番番业务部
• 公众号『非写不可』作者
3. • 01 案例：营销&销售型SaaS系统
• 02 改造：基于DDD、BFF和API-First
• 03 总结：经验与思考
4. 业务概述：百度爱番番
聊(客服)
•
•
•
百度
广告
•
•
•
•
原百度商桥
营销咨询
智能客服接待
拓(公域)
•
•
•
•
•
•
营销玩法
培育自动化
CDP
其他
广告
追（CRM）
线索归集中台
多场景跟进转化
投放优化数据供给
公私域整合营销+CRM
SEM-百度
SEM-其他投放平台
垂类深耕
拓(私域)
•
SaaS * 40万+企业客户
私域
流量
•
Java、Go、多端
5. 挑战：如何管理复杂度
业务复杂：多租户多⻆色多流程
系统复杂
对象复杂
6. 系统现状：自然生⻓下的无序
线索（导入）
线索收集
线索标记
Redis
线索（开放）
线索创建
线索（变更）
线索变更
线索变更
ü
跟进记录
ü 数据共享，非接口通信
接口膨胀，充斥前端逻辑
ü 链路⻓，缺乏柔性
ü 业务模型贫血、逻辑散落
ü
客户
DB
线索池
跟进记录
线索创建
客户
模块划分混乱（发散式、
散弹式修改）
7. 系统外现状：交付效率低
产品
•
•
•
多产品线、边界模糊
主路径复杂、场景化弱
模块复用度低
工程
组织
• 分层粗糙，只有sdk/service层 • 接口文档缺失
• 各自定义公共utility类 • 业务知识流失
• 接口设计⻛格多样 • 需求沟通效率低
• 自动化测试率低 • 缺乏相互信任
8. • 01 案例：营销&销售型SaaS系统
• 02 改造：基于DDD、BFF和API First
• 03 总结：经验与思考
9. 思路：效能工具箱里有什么？
架构层
微服务
中台
DDD
流程工具
DDD
代码层
代码重构
设计模式
DDD
敏捷
l 局部 VS 系统
l 技术 VS 业务
l 短期 VS ⻓期
CICD
基础层
Docker
K8s
Mesh
DevOps
10. 思路：全生命周期管理系统复杂度
目标
节奏
打法
统一语言
结构化建模业务
API First
领域建模
需求
设计
理论储备
示例项目 小范围试点
深度改造 标杆案例
增量推全 存量按需
四重边界
架构关注点分离
DDD
模块弱依赖
编码和设计匹配
理念宣贯
⻣架代码
编码规范
分层架构
编码
架构
事件驱动
BFF
11. 落地1：聚焦组织效能的顶层设计
UI/Open API
BFF
API Gateway
1. 分层架构组织代码
微服务A 微服务B
DDD分层⻣架 DDD分层⻣架
DDD框架
2. DDD⻛格的数据访问层
领域事件
SDK
领域事件
SDK
3. 领域事件驱动的异步通信
MySQL
数仓
4. 展示逻辑和领域逻辑解耦
ES
DDD框架
5. API-First贯穿开发全流程
12. 落地2：更合理的微服务
线索BFF
1. DDD指导模块划分
线索收集
线索收集
线索清洗
DB
4. 独立的BFF模块
线索分配
MQ
分配规则
分配记录
2. 链路异步化
3. 数据私有，靠接口通信
客户BFF
线索跟进
MQ
线索标记
MQ
MQ
客户
线索变更
DB
DB DB
标签 跟进记录
DB DB
定时任务
13. 落地3：更好的分层架构
1. 关注点分离
2. 领域层纯粹、依赖倒置
3. 脚手架、编码规范、自研ddd-framework
4. 组件化（数据访问、领域事件）
14. 落地4：更合理的模型
1. 业务逻辑（自上向下、动态）
2. 建模（自下向上、静态）
15. 落地5：代码示例
16. 落地6：运行态数据流
17. 落地7：更友好的领域事件架构
1. 围绕聚合识别领域事件
2. 不用操心事务一致性（发件箱模式）
3. 不用操心消息队列收发细节
4. 不用操心可用性（消息队列灾备）
18. 落地8：BFF（Backend For Frontend）
方案
问题
端展示灵活多变
落地
前端
团队情况
- 多端适配 - 前端模式、后端模式
- 字段裁剪 - BFF模块粒度
graphql client
BFF
- 接口组合
开发效率
- 编写BFF接口效率
服务端能力沉淀
- 业务模型稳定
- 接口职责单一、正交
schema
resolver
service
Egg/KoA
- 消费方按需查询
运维效率
- 融入现有服务框架
- 和API网关的关系
API GW
前端模式 + GraphQL + Mesh
19. 落地9：API-First贯穿开发测试流程
•
•
•
•
•
•
接口开放效率
接口diff监控
接口分级与SLA
自动构建mock
自动构建契约测试
快速生成接口测试
治理
理念
•
•
API是一等公⺠
Day 1 可开放
API First
测试
•
设计 •
编码
•
•
接口先行、并行开发、单测效率
swagger注解/注释，CI流水线发布
从消费者视⻆构建API能力
API匹配DDD聚合，体现业务能力
20. 落地10：效果收益
显性收益
隐性收益
ü 落地了100+模块、所有接口接入在线化文档 ü 提高了产研团队协同效率（统一语言、共同建模）
ü 深度重构了销售域、IM沟通域、私域营销域3大领域 ü 减少了团队间的耦合（模块和团队的边界划分更合理）
ü 销售域代码行数减少40%、领域接口数减少35%、 ü 提高了新服务开发效率（融入DDD的开发规范、项目代
bug数减少30%
码⻣架）
ü IM沟通域新手上手时间加快60%、模块数减少40% ü 经验输出到了公司内多个部⻔项目和技术大会
ü 提高了Open API暴露效率（2天 ->0.5天） ü 在部⻔内开拓了一个技术成⻓方向
21. • 01 案例：营销&销售型SaaS系统
• 02 改造：基于DDD、BFF和API-First
• 03 总结：经验与思考
22. 因地制宜：选择适合的落地方式
什么项目适合DDD？
是个什么样的业务？
- 复杂一点的（从流程分支、概念/
对象、规则等数量判断）
架构和代码质量怎么样？
- 模块边界不清、接口设计不正交、
概念失配、后端逻辑不纯粹
组织文化怎么样？
- 追求高效能、做事精益求精
- 负责人有远⻅、⻣干能落地
什么时机适合DDD？
是否完整经历DDD全阶段？
业务变化时：
- 有更多资源投入时 新项目：
- 聚焦领域划分、核心领域的主
流程拆解和概念建模
技术架构变化时：
- 需要先理解业务 存量项目改造：
- 聚焦分析和设计阶段
组织调整时：
- 模块交接、关停并转 存量项目中台化：
- 建议经历DDD全阶段
23. ⻓期主义：存量竞争下的不错选择
重新认识DDD：
团队成⻓：
• 凡是聚焦业务的实践经验都不能拿来主义 • 统一语言、业务理解先行能让团队走的更远
• 不要把DDD当作锤子、根据业务目标、项目资源、团队现状 • 领域知识的传承和沉淀
不同程度地尝试落地 • 重视设计质量、重视思考和抽象能力的文化
重视设计，设计不是一种负担，毕竟不好的设计也得设计 • 提升业务研发人员的成就感、新的技术提升方向
•
实施忠告：
• 不要陷入细节纠缠，比如某个聚合的设计合理性、事务
• 勇敢迈出一小步：哪怕是对⻬命名、识别隐性概念
• DDD带来⻓期和隐性收益、不能急功近利
24. 展望：效能是个绕不开的话题
DDD的诉求会更大：
DDD的生态会更丰富：
• 存量市场竞争倒逼企业练内功，向产研团队要效率 • DDD与API First、BFF等相关理念结合
• ToB行业发展引入更多复杂业务系统 • 更重视API的地位、API First变得更流行
• 云原生、数字化技术发展 • BFF结合Serverless的落地案例涌现
• ToC存量系统的演进和开发效率 • 更多技术框架、案例分享、书籍出现
• 更频繁的系统间能力复用和集成
25.