当技术重构遇上DDD，如何实现业务、技术双赢？

百度Geek说正在上传…重新上传取消​架构师 @ 百度

全文9000字，预计阅读时间21分钟

一、困境：项目背景

爱番番沟通基于百度商桥快速完成了产品功能和技术架构的从无到有，但同时也继承了百度商桥历史功能繁杂、技术架构陈旧的缺点。为了能更好地服务于爱番番沟通将来的产品演进，提高产研能效，需要从实际问题出发，聚焦主要矛盾，对产品架构和业务架构进行重构。

为了更好的理解本文内容，以下是必要的名词解释：

1.1 爱番番沟通是什么？

爱番番沟通是连接访客和商家的在线咨询工具。一方面访客可以随时随地咨询，缩短访客获取服务的途径，另一方面商家也可以快速响应并提供服务。同时在推广场景中，商家还可以根据访客的咨询内容反哺回上游广告通路，优化投放模型，提升营销转化效果。

1.2 为什么要重构？

百度商桥经历了几次不同的产品定位和多年版本迭代，产研团队也换了几波人。客户问题较多，架构长期缺乏系统性治理。给产研团队带来多个层面的掣肘：

1. 团队内对产品的主要业务逻辑没有知识储备。经常需要研发去翻阅项目代码东拼西凑出现有逻辑的大致模样。

2. 客户反馈问题数量居高不下，典型问题如：

• 访客进站识别不及时，客服感知不到访客已进站。访客离站识别不及时，容易误导客服向离站的访客继续发起沟通，引发沟通不畅的表象；

• 访客的广告相关信息（来源、搜索词、关键词）获取不及时、不完整；

• 访客全生命周期内的行为数据有概率性延迟和缺失；

• 商家欢迎语、自动回复发送顺序错乱，不触发发送等；

• 服务稳定性引起的登录失败，消费发送失败、移动端消息提醒不及时等；

• 还有一部分客户问题属于新需求范畴，比如咨询组件样式灵活定制、支持离线沟通。

1. 团队士气低落，生产力不高。疲于应对救火问题，难以承接较大功能需求开发。

2. 现有架构陈旧，模块繁杂，长期缺乏治理。模块数量和人员规模失配，小需求可能涉及多个模块改动。存在大量陈旧代码，只能不停地进行『打补丁』方式修复问题。

二、反思：定义问题和挑战

面对当前困境，整个产研团队都意识到了需要尽快做出改变。透过现象找本质，上述现象背后的关键问题是什么呢？又会面临哪些挑战呢？

2.1 定义问题

通过进一步分析问题的根本原因，可以把问题分为以下几类：

【产品层面】产品方向及定位不明确，功能层级及分类不清晰

• 产品演进方向不清晰，业务领域主次不清，各模块的业务主路径不清晰。平时开发都是堆砌功能，导致不少业务场景存在使用体验的卡点；

• 由于历史原因系统支持的角色冗余且复杂，既有平台型角色比如支持百度顾问和商家直接沟通。又有B端其他角色比如支持销售直接查看线索；

• 从PC时代到移动时代，但是产品还保留着一些历史兼容的痕迹。比如常用语是按照PC和移动进行一级分类，站点样式类型只能设置一个端。

旧版客户端界面示例

【架构层面】客户端架构多年未演进，功能迭代难以为继

• 客户端仅支持Windows系统且架构一直未演进，技术栈基于C++，和团队主要技术栈偏离，只能艰难维护，无力承接新功能需求。迫切需要演进为能跨平台、主流的、前端技术栈；

• 访客侧前端还未做到前后端分离架构，体验和开发效率大打折扣。

【架构层面】服务端架构的基础沟通层待演进

沟通协议层作为沟通产品非常重要的一环，还存在架构方面的不足：

• 多种网络连接协议下的稳定性需提高；

• 和不同端的消息发送性能需提高。

【架构层面】服务端架构的业务层待演进

业务层包含 20+ 服务模块，主要的业务逻辑采用共享库的方式维护，导致模块边界不清，数据链路混乱，功能重叠耦合严重，迫切需要演进为主流微服务架构。

• 模块内职责不够内聚，模块间调用关系耦合高；

• 同样的数据存在多份存储，数据一致性存在问题；

• 数据流的同步异步传输链路混乱。

【架构层面】整体服务端架构自运维成本高，可维护性很低

历史遗留系统中需要运维多种自运维中间件，导致团队不能聚焦业务功能开发。既降低了研发生产力，也给系统稳定性带来巨大挑战。

• 自运维了反向代理 Nginx 集群、Zookeeper 集群、Storm 集群、Kafka 集群、Solr 集群、Prometheus 集群；

• 离部门的主服务端集群面向云原生的服务治理架构还有不小差距。

【组织层面】产研团队整体对业务的理解不够且未拉齐

• 业务架构和研发架构长期脱钩，导致团队对大到沟通行业小到具体某个模块的领域知识沉淀缺乏，迫切需要在产研层面拉齐现有认知；

• 在团队达成共识的基础上将来才能形成随产品快速演进从而快速迭代领域认知的正向循环。

2.2 认清挑战

归因清楚问题后，重构的方向逐渐清晰起来。但执行落地阶段也会面临着业务演进压力，原架构基础薄弱，资源短缺等挑战。

架构陈旧，代码里有不少隐蔽的『坑』

从以往经历看，有时候一个很小的改动，看起来很有把握的一次上线也可能造成客户问题。一方面代码中缺乏设计的地方多，另一方面整体回归测试覆盖不全。组内自嘲这种状态为『每一行代码都刚刚好』，不能多也不能少。

重构和业务演进既要又要

这个挑战是大部分团队都会遇到的，业务不可能停止演进等待技术重构。如何能在不影响已有业务且保证部分高优业务需求正常迭代的情况下进行重构是必须要回答的问题。

不能仅仅是重构，客户可感知的体验要更好

涉及客