随着服务包业务的快速发展，新增一个服务包类型需要 5-8 人天的高昂成本，原有的单体架构暴露出严重的开发效率瓶颈。本文以淘宝闪购服务包系统为案例，探索如何借助 AI 技术辅助领域驱动设计（DDD）落地，实现架构的智能化演进。
一、背景
1.1 改造背景
原有系统在快速发展过程中，单体架构逐渐成为业务扩展的瓶颈，主要体现在以下几个方面：
- 开发成本高昂：每次新增服务包类型需要在 8 个核心文件、15-20 个方法中进行重复性修改，涉及 200-300 行代码变更
- 重复代码泛滥：商品类型判断逻辑在 10 个文件中重复出现，维护成本极高
- 架构耦合严重：3800 行的单体业务服务类混合了商品、价格、合同等多个领域逻辑
- 扩展风险高：任何新增功能都可能引入回归问题，影响现有业务稳定性
1.2 改造目标
采用 DDD（领域驱动设计）思想结合 AI 辅助开发进行架构重构，探索智能化架构演进路径：
- AI 驱动架构设计：利用 AI 分析现有代码结构和业务逻辑，自动识别领域边界和上下文划分，辅助设计合理的 DDD 架构模型
- 智能化模型落地：通过 AI 代码生成能力，自动化完成领域模型、服务接口、数据转换等重复性代码编写，显著提升开发效率
- 持续模型分析优化：建立 AI 驱动的代码质量监控体系，实时分析架构健康度、代码复杂度和重复度，持续优化模型设计
- 开发成本大幅降低：探索将新增服务包类型的开发成本从传统的 5-8 人天大幅降低至配置化实现
- 架构演进智能化：构建可持续演进的智能架构体系，支持业务快速变化和技术栈升级
二、架构设计阶段
2.1 AI 拆解限界上下文
问题：你是一个 DDD 专家，根据现有代码 v6 这个 package 下的类帮我抽象下上下文。
AI 回答：
2.2 人工介入修正限界上下文
从上一步可以看出，AI 拆解的限界上下文是基于 package 结构进行拆分，未能深入分析业务语义，这是 AI 的薄弱环节，需要人工介入修正。经过人工分析后的限界上下文如下：
2.3 通过 AI 细化限界上下文
基于上述人工拆分的上下文，逐步通过 AI 细化上下文文档，以商品上下文为例：
问题：根据人工拆解限界上下文部分，从原有 me.ele.newretail.contract.v6.domain 包下，帮我抽象出商品上下文的类，Repo、Service，类用 Domain 结尾，Repo 用 DomainRepo 结尾，Service 用 DomainService 结尾，输出成表格，包含方法和属性，就放到当前这个文档最后。
经过多轮迭代优化后的商品上下文设计如下图所示：
三、代码实现阶段
3.1 基于文档生成代码骨架
基于准备好的技术文档《技术方案--服务包模型升级.md》进行代码生成：
问题：严格根据该技术文档帮我在 v61.domain 包下生成代码骨架。
3.2 AI 辅助代码实现
案例 1：API 转换实现
问题：queryConfirmableProgramList 第 157 行开始，帮我把 List shopConfirmableContracts 转换成 ConfirmableServiceProgramDTO 参考 queryConfirmableProgramList 链路原有代码。
实现效果：新增 734 行代码，人工修正 25 行，准确率高达 96.6%。
案例 2：版本比对工具实现
问题：帮我写个比对 queryConfirmableProgramList 和 queryConfirmableProgramList 两个方法返回结果是否一致的工具类叫 ProgramVersionComparisonUtil 放到 v61 包下。
实现效果：新增比对代码 3098 行，人工修正 12 行，准确率高达 99.6%。
四、重构效果分析
4.1 架构解耦度分析
问题：帮我对比下 queryConfirmableProgramList 和 queryConfirmableProgramList 从分层、域解耦等维度进行分析。
以 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;
}
// 类似的重复方法还有：
// validatePlatformDeliveryGoods()
// validateSelfDeliveryGoods()
// buildSuperClientProgram()
// buildPlatformDeliveryProgram()
// buildSelfDeliveryProgram()
问题点：
- 业务逻辑高度耦合在一个方法中
- 商品类型判断逻辑重复出现
- 扩展点机制复杂，难以维护
- 缺乏清晰的职责分离
重构后实现
实现特点：
- 代码行数：主方法 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% |
| 价格计算 |
内嵌在查询逻辑中 |
独立的价格计算服务 |
价格逻辑内聚 |
| 活动处理 |
分散的活动匹配逻辑 |
统一的活动服务 |
活动逻辑集中管理 |
| 扩展性 |
修改需要改动多处代码 |
新增功能只需扩展对应上下文 |
支持开闭原则 |
| 测试性 |
难以进行单元测试 |
每个上下文可独立测试 |
测试覆盖率提升 |
重构前核心问题点
1. 重复代码泛滥
switch51ConfigGateway.superClientGoodId().equals() 判断逻辑在 10 个文件中重复buildDeliveryProgramTypeEnum 方法在 2 个类中完全重复- 商品类型判断逻辑分散在多个 Ability 类中
2. 业务逻辑耦合
- 价格计算直接依赖商品属性
- 合同创建逻辑与数据持久化混合在一起
- 活动优惠逻辑散落在查询、计算、签约等多个环节
3. 扩展性差
- 新增商品类型需要在多处添加 switch 判断
- 新增活动类型需要修改多个 Ability 类
- 新增合同模板需要修改 8 个文件约 15-20 个方法
4.2 重复代码模式识别
问题：帮我对比下 queryConfirmableProgramList 和 queryConfirmableProgramList 这两个方法链路中的代码重复度。
通过代码分析，发现以下重复代码模式：
商品类型判断逻辑重复
在以下 10 个文件中发现相同的判断逻辑：
重复代码示例：
// 在多个文件中重复出现的商品类型判断逻辑
if (switch51ConfigGateway.superClientGoodId().equals(goods.getGoodsId())) {
// 超客商品特殊处理逻辑
// 这段逻辑在10个不同文件中重复出现
}
重复出现的文件：
DefaultConfirmableProgramQueryExt.java - buildDeliveryProgramTypeEnum 方法ProgramConverter.java - buildDeliveryProgramTypeEnum 方法ProgramAbilityImpl.java - signEUnion 方法ProgramAbilityImpl.java - getSignGoodRequest 方法ProgramQueryAbilityImpl.java - 多个方法ProgramSignAbilityImpl.java - 多个方法DefaultProgramQueryExt.java - 查询逻辑ProgramBizServiceImpl.java - 三个核心方法ProgramTypeEnumBuilder.java - 类型构建逻辑DeliveryProgramConverter.java - 转换逻辑
buildDeliveryProgramTypeEnum 方法重复
该方法在 2 个类中完全重复：
DefaultConfirmableProgramQueryExtProgramConverter
重复代码消除效果
4.3 新增服务商品改动点对比
问题：综合上面的分析，帮我对比下 v61 和 v6 两个代码链路在新增一个服务商品时的改动点。
| 重构前新增服务商品需要修改的文件 |
重构后新增服务商品需要修改的文件 |
| 核心业务服务层修改：<br><br>1. ProgramBizServiceImpl.java<br>- queryConfirmableProgramList 方法<br>- queryConfirmableCombineProgramList 方法<br>- signProgram 方法<br>- 需要在 3 个核心方法中都添加新的商品类型判断逻辑<br><br>扩展点和转换层修改：<br><br>2. DefaultConfirmableProgramQueryExt.java<br>- buildDeliveryProgramTypeEnum 方法<br>- queryConfirmableProgramList 扩展逻辑<br><br>3. ProgramConverter.java<br>- buildDeliveryProgramTypeEnum 方法（与上面重复）<br>- 领域对象转换逻辑<br><br>能力层修改：<br><br>4. ProgramAbilityImpl.java<br>- signEUnion 方法<br>- getSignGoodRequest 方法<br><br>5. ProgramQueryAbilityImpl.java<br>- 多个查询相关方法<br>- 商品类型过滤逻辑<br><br>6. ProgramSignAbilityImpl.java<br>- 多个签约相关方法<br>- 签约流程判断逻辑<br><br>工具类和构建器修改：<br><br>7. DeliveryProgramConverter.java<br>- 配送方案转换逻辑<br>- 商品类型映射<br><br>8. ProgramTypeEnumBuilder.java<br>- 枚举构建逻辑<br>- 新类型枚举定义 |
领域模型层修改：<br><br>1. ContractTemplateDomain.java<br>- 添加新的合同模板配置<br>- 商品组合定义<br>- 模板属性扩展<br><br>商品上下文修改（可选）：<br><br>2. GoodsDomain.java<br>- 仅当涉及新的商品属性时才需要修改<br>- 配送类型定义<br>- 商品特性扩展<br><br>数据配置修改：<br><br>3. 数据库配置<br>- 在合同模板表中添加新模板记录<br>- 配置商品组合关系<br>- 设置模板生效规则<br><br>可能的扩展修改：<br><br>4. 枚举类扩展（如需要）<br>- 新增合同类型枚举<br>- 商品类型枚举扩展 |
改动点对比总结
五、AI 架构升级总结
5.1 AI 架构升级价值和效果
核心价值
- 智能分析：快速识别重复模式、梳理依赖关系，提供现状分析
- 高效生成：代码生成准确率 99.0%，速度提升 8-10 倍
- 质量保障：架构评估、最佳实践指导、风险预警
实施要点
- 人机分工：AI 负责重复性工作，人类负责业务决策和质量把关
- 渐进策略：分析→设计→实现→验证，每阶段明确标准
- 质量控制：AI 代码必须人工 review，建立自动化检查
实际效果
- 效率提升：新增 3832 行代码，AI 生成 70%+，重构周期缩短 75%+
- 质量改善：代码量减少 52%，重复代码消除 100%，改动点从 8 个文件减少到 1-2 个
- 业务价值：开发成本从 5-8 人天降低到配置化，支持快速迭代
5.2 AI 架构升级总结展望
AI 辅助架构升级证明了人机协作的有效性，让工程师从重复编码中解放，专注于架构设计和业务创新。这将成为软件工程的新常态。
通过本次实践，我们验证了 AI 在复杂系统重构中的巨大价值。从限界上下文识别、领域模型设计到代码生成，AI 都展现出了强大的辅助能力。未来，随着 AI 技术的不断进步，智能化架构演进将成为软件开发的标准范式，帮助团队更高效地应对业务挑战。
更多关于 架构设计 和 AI 技术 的实践经验，欢迎访问云栈社区交流探讨。
发表于 昨天 19:35
|
查看: 3|
回复: 0
