本文以淘宝闪购服务包系统为实战案例，深入探讨如何借助 人工智能 技术辅助领域驱动设计（DDD）落地，实现从单体架构向现代化架构的平滑演进。在 云栈社区 的众多技术实践中，这种结合 AI 提效的重构思路正成为行业新趋势。
1. 项目背景与痛点
1.1 改造背景
随着服务包业务的飞速扩张，原有的单体架构逐渐显露出严重的效率瓶颈。数据显示，新增一个服务包类型平均耗时高达 5-8 人天，主要面临以下挑战：
- 开发成本高昂：每次新增类型需修改 8 个核心文件、涉及 15-20 个方法，伴随 200-300 行代码的重复性变更。
- 重复代码泛滥：商品类型判断逻辑在 10 个不同文件中反复出现，维护成本呈指数级上升。
- 架构耦合严重：核心业务服务类膨胀至 3800 行，混合了商品、价格、合同等多个领域的逻辑，缺乏清晰边界。
- 扩展风险不可控：牵一发而动全身，任何新增功能都极易引入回归问题，严重影响业务稳定性。
1.2 改造目标
本次重构旨在采用 DDD（领域驱动设计）思想结合 AI 辅助开发，探索一条智能化的架构演进路径：
- AI 驱动架构设计：利用 AI 分析现有代码结构与业务逻辑，自动识别领域边界，辅助划分限界上下文。
- 智能化模型落地：通过 AI 代码生成能力，自动化完成领域模型、服务接口、数据转换等标准化代码，显著提升开发效率。
- 持续模型优化：建立基于 AI 的代码质量监控，实时分析架构健康度，确保持续演进。
- 降本增效：将新增服务包类型的开发成本从 5-8 人天降低至配置化实现。
- 架构演进智能化：构建支持业务快速变化和技术栈升级的可持续架构体系。
2. 架构设计阶段：AI 辅助领域建模
2.1 AI 初步拆解限界上下文
在重构初期，我们尝试让 AI 扮演 DDD 专家角色，对现有代码包进行分析。
Prompt：
你是一个 DDD 专家，根据现有代码 v6 这个 package 下的类帮我抽象下上下文。
AI 反馈：
AI 给出了基于现有包结构的初步拆分建议。
2.2 人工介入修正
从 AI 的初步结果可以看出，其拆解主要依赖于物理包结构，未能深入理解业务语义，这正是当前 AI 在架构设计中的薄弱环节。因此，我们需要人工介入进行语义级别的修正。
修正后的限界上下文视图：
2.3 AI 细化上下文设计
基于人工修正后的顶层设计，我们继续利用 AI 细化具体的类设计。以商品上下文为例：
Prompt：
根据人工拆解限界上下文部分，从原有 me.ele.newretail.contract.v6.domain 包下，帮我抽象出商品上下文的类。Repo、Service 类用 Domain 结尾，Repo 用 DomainRepo 结尾，Service 用 DomainService 结尾，输出成表格，包含方法和属性。
经过多轮迭代优化后的商品上下文设计：
3. 代码实现阶段：AI 自动化生成
3.1 基于文档生成代码骨架
利用准备好的技术文档《技术方案--服务包模型升级.md》，我们可以快速生成符合 Java 规范的代码骨架。
Prompt：
严格根据该技术文档帮我在 v61.domain 包下生成代码骨架。
3.2 AI 辅助逻辑实现
在具体的业务逻辑迁移和工具类编写上，AI 展现了极高的准确率。
案例 1：API 数据转换
Prompt：
queryConfirmableProgramList 第 157 行开始，帮我把 List shopConfirmableContracts 转换成 ConfirmableServiceProgramDTO，参考 queryConfirmableProgramList 链路原有代码。
效果：
新增 734 行代码，人工仅修正 25 行，准确率高达 96.6%。
案例 2：版本比对工具
Prompt：
帮我写个比对 queryConfirmableProgramList 和 queryConfirmableProgramList 两个方法返回结果是否一致的工具类，叫 ProgramVersionComparisonUtil，放到 v61 包下。
效果：
新增比对代码 3098 行，人工修正 12 行，准确率高达 99.6%。
4. 重构效果全方位分析
4.1 架构解耦度对比
我们以核心方法 queryConfirmableProgramList 为例，从分层、域解耦等维度对比重构前后的 后端 & 架构 变化。
重构前：单体泥球
代码特征：
- 代码量：主方法 42 行 + 核心调用链路约 1,500 行。
- 复杂度：高度耦合，业务逻辑与数据组装混合。
- 重复度：大量硬编码的商品类型判断。
@Override
public SingleResponse<ConfirmableServiceProgramDTO> queryConfirmableProgramList(ConfirmableProgramQuery query){
try {
// step.1 参数校验和门店信息获取
if (query == null || query.getShopId() == null) {
return SingleResponse.buildFailure("参数不能为空");
}
ShopInfoDTO shopInfo = shopQueryAbility.queryShopInfo(query.getShopId());
if (shopInfo == null) {
return SingleResponse.buildFailure("门店不存在");
}
// step.2 获取可签方案列表 - 复杂的扩展点机制
List<ServiceProgramDTO> programs = new ArrayList<>();
// 获取所有商品信息
List<GoodsDTO> allGoods = goodsQueryAbility.queryAllGoods();
for (GoodsDTO goods : allGoods) {
// 重复的商品类型判断逻辑 - 问题点1
if (switch51ConfigGateway.superClientGoodId().equals(goods.getGoodsId())) {
// 超客商品特殊处理
if (validateSuperClientGoods(goods, shopInfo)) {
ServiceProgramDTO program = buildSuperClientProgram(goods, shopInfo);
programs.add(program);
}
} else if (switch51ConfigGateway.platformDeliveryGoodId().equals(goods.getGoodsId())) {
// 平台配送商品特殊处理
if (validatePlatformDeliveryGoods(goods, shopInfo)) {
ServiceProgramDTO program = buildPlatformDeliveryProgram(goods, shopInfo);
programs.add(program);
}
} else if (switch51ConfigGateway.selfDeliveryGoodId().equals(goods.getGoodsId())) {
// 自配送商品特殊处理
if (validateSelfDeliveryGoods(goods, shopInfo)) {
ServiceProgramDTO program = buildSelfDeliveryProgram(goods, shopInfo);
programs.add(program);
}
}
// ... 更多商品类型判断
}
// step.3 价格计算 - 内嵌在业务服务中
for (ServiceProgramDTO program : programs) {
// 硬编码的价格计算逻辑 - 问题点2
if (program.getDeliveryType().equals("PLATFORM")) {
program.setCommissionRate(new BigDecimal("0.08")); // 8%
program.setDeliveryFee(calculatePlatformDeliveryFee(program, shopInfo));
} else if (program.getDeliveryType().equals("SELF")) {
program.setCommissionRate(new BigDecimal("0.10")); // 10%
program.setDeliveryFee(calculateSelfDeliveryFee(program, shopInfo));
}
// 保底价计算
BigDecimal basePrice = priceCalculateAbility.calculateBasePrice(
program.getGoodsId(), shopInfo.getCategoryId());
program.setBasePrice(basePrice);
}
// step.4 活动处理 - 分散的活动逻辑
List<ActivityDTO> activities = activityQueryAbility.queryShopActivities(query.getShopId());
for (ServiceProgramDTO program : programs) {
for (ActivityDTO activity : activities) {
// 活动匹配逻辑分散 - 问题点3
if (activity.getType().equals("COMMISSION_DISCOUNT")) {
if (activity.getTargetGoods().contains(program.getGoodsId())) {
BigDecimal discountRate = activity.getDiscountRate();
BigDecimal newRate = program.getCommissionRate().subtract(discountRate);
program.setCommissionRate(newRate);
program.setActivityId(activity.getActivityId());
}
} else if (activity.getType().equals("DELIVERY_DISCOUNT")) {
// 配送费优惠逻辑
if (activity.getTargetGoods().contains(program.getGoodsId())) {
BigDecimal discountFee = activity.getDiscountAmount();
BigDecimal newFee = program.getDeliveryFee().subtract(discountFee);
program.setDeliveryFee(newFee);
}
}
}
}
// step.5 构建返回结果
ConfirmableServiceProgramDTO result = new ConfirmableServiceProgramDTO();
result.setShopId(query.getShopId());
result.setPrograms(programs);
result.setTotalCount(programs.size());
return SingleResponse.of(result);
} catch (Exception e) {
logger.error("查询可签方案失败，shopId：{}，异常：{}",
query.getShopId(), e.getMessage(), e);
return SingleResponse.buildFailure("查询失败");
}
}
// 重复的商品校验方法 - 在多个地方重复出现
private boolean validateSuperClientGoods(GoodsDTO goods, ShopInfoDTO shopInfo){
// 重复的商品类型判断逻辑
if (!switch51ConfigGateway.superClientGoodId().equals(goods.getGoodsId())) {
return false;
}
// 区域校验逻辑内嵌
List<String> allowedCities = goods.getAllowedCities();
if (!allowedCities.contains(shopInfo.getCity())) {
return false;
}
// 品类校验逻辑内嵌
List<Long> allowedCategories = goods.getAllowedCategories();
if (!allowedCategories.contains(shopInfo.getCategoryId())) {
return false;
}
return true;
}
重构后：清晰的领域编排
代码特征：
- 代码行数：主方法 37 行 + 核心调用链路约 720 行。
- 复杂度：逻辑清晰，通过领域服务解耦。
- 职责分离：每个上下文专注自身的业务逻辑。
@Override
public SingleResponse<ConfirmableServiceProgramDTO> queryConfirmableProgramList(ConfirmableProgramQuery query){
// step.1 获取门店信息 - 门店上下文
ShopDomain shopDomain = shopDomainService
.getShop(query.getShopId());
// step.2 查询可签合同列表 - 合同上下文
List<ShopContractDomain> contracts =
shopContractDomainService
.getShopConfirmableContractList(shopDomain);
// step.3 商品校验 - 商品上下文
contracts = goodsDomainService
.filterAvailableContracts(contracts, shopDomain);
// step.4 价格计算 - 价格上下文
contracts = priceDomainService
.enrichContractPrice(contracts);
// step.5 活动匹配 - 活动上下文
contracts = activityDomainService
.applyActivityDiscount(contracts, shopDomain);
// step.6 转换为DTO返回
ConfirmableServiceProgramDTO result =
buildConfirmableServiceProgramDTO(contracts);
return SingleResponse.of(result);
}
详细改进维度表
| 维度 |
重构前特点 |
重构后特点 |
改进效果 |
| 代码结构 |
主方法 42 行 + 链路 ~1,500 行 |
主方法 37 行 + 链路 ~720 行 |
代码量减少 52%，复杂度显著降低 |
| 职责分离 |
所有逻辑混合在业务服务中 |
按上下文分离，各司其职 |
职责单一，易于维护 |
| 商品处理 |
重复的商品类型判断逻辑 |
统一的商品校验服务 |
重复代码消除 100% |
| 价格计算 |
内嵌在查询逻辑中 |
独立的价格计算服务 |
价格逻辑高内聚 |
| 活动处理 |
分散的活动匹配逻辑 |
统一的活动服务 |
活动逻辑集中管理 |
| 扩展性 |
修改需改动多处代码 |
新增功能只需扩展对应上下文 |
支持开闭原则 |
| 测试性 |
难以进行单元测试 |
每个上下文可独立测试 |
测试覆盖率大幅提升 |
4.2 重复代码模式识别与消除
通过代码分析，我们识别出系统中存在大量的重复代码模式，特别是商品类型的判断逻辑。
重复代码示例：
// 在多个文件中重复出现的商品类型判断逻辑
if (switch51ConfigGateway.superClientGoodId().equals(goods.getGoodsId())) {
// 超客商品特殊处理逻辑
// 这段逻辑在10个不同文件中重复出现
}
这种逻辑在 DefaultConfirmableProgramQueryExt.java、ProgramConverter.java、ProgramAbilityImpl.java 等 10 个核心文件中反复出现。重构后，这些重复逻辑被统一封装在领域服务中，消除了维护隐患。
4.3 扩展性对比：新增服务商品
重构前：
新增一个服务商品，需要修改 8 个文件，涉及核心业务层、扩展层、能力层、工具类等多个模块，且需要在 3 个核心方法中添加 if-else 判断。
重构后：
仅需修改 1-2 个文件（主要是 ContractTemplateDomain 和数据库配置），大部分逻辑通过配置化实现，无需修改核心代码。
5. 总结与展望
5.1 核心价值
- 智能分析：快速识别重复模式、梳理依赖关系，提供客观的现状分析。
- 高效生成：AI 代码生成准确率达 99.0%，编码速度提升 8-10 倍。
- 质量保障：提供实时的架构评估、最佳实践指导和风险预警。
5.2 实施效果
- 效率提升：重构周期缩短 75%+，AI 生成代码占比超过 70%。
- 质量改善：核心链路代码量减少 52%，重复代码彻底消除。
- 业务价值：开发成本从 5-8 人天降低至配置化，极大提升了业务响应速度。
本次 AI 辅助架构升级证明了人机协作的巨大潜力。AI 将工程师从繁琐的重复编码中解放出来，使其能专注于核心架构设计和业务创新。这不仅是一次技术重构，更是软件工程模式的一次重要演进。
发表于 5 天前
|
查看: 24|
回复: 0
