一、背景
1、改造背景
随着服务包业务的快速发展,新增一个服务包类型需要5-8人天的高昂成本,原有的单体架构暴露出严重的开发效率瓶颈:
2、改造目标
采用DDD(领域驱动设计)思想结合AI辅助开发进行架构重构,探索智能化架构演进路径:
二、架构设计阶段
1、AI拆解限界上下文
问题:你是一个DDD专家,根据现有代码 v6 这个package下的类帮我抽象下上下文。
AI回答:
2、人工介入修正限界上下文
从上一步可以看出,AI拆解的限界上下文是基于package结构进行拆分,未能深入分析业务语义,这是AI的薄弱环节,需要人工介入修正。经过人工分析后的限界上下文如下:
3、通过AI细化限界上下文
基于上述人工拆分的上下文,逐步通过AI细化上下文文档,以商品上下文为例:
问题:根据人工拆解限界上下文部分,从原有 me.ele.newretail.contract.v6.domain 包下,帮我抽象出商品上下文的类,Repo、Service,类用Domain结尾,Repo用DomainRepo结尾,Service用DomainService结尾,输出成表格,包含方法和属性,就放到当前这个文档最后。
经过多轮迭代优化后的商品上下文设计如下图所示:
三、代码实现阶段
1、基于文档生成代码骨架
基于准备好的技术文档《技术方案--服务包模型升级.md》进行代码生成:
问题:严格根据该技术文档帮我在 v61.domain 包下生成代码骨架。
2、AI辅助代码实现
案例1:API转换实现
问题:queryConfirmableProgramList 第157行开始,帮我把 List shopConfirmableContracts 转换成 ConfirmableServiceProgramDTO 参考 queryConfirmableProgramList 链路原有代码。
实现效果:新增734行代码,人工修正25行,准确率高达 96.6%。
案例2:版本比对工具实现
问题:帮我写个比对 queryConfirmableProgramList 和 queryConfirmableProgramList 两个方法返回结果是否一致的 工具类 叫 ProgramVersionComparisonUtil 放到 v61 包下。
实现效果:新增比对代码 3098行,人工修正12行,准确率高达99.6%。
四、重构效果分析
1、架构解耦度分析
问题:帮我对比下queryConfirmableProgramList 和 queryConfirmableProgramList 从分层、域解耦等维度进行分析。
以queryConfirmableProgramList方法重构为例进行对比分析:
重构前后实现对比
重构前实现
实现特点:
核心实现逻辑:
@Override
public SingleResponse
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 programs = new ArrayList<>();
// 获取所有商品信息
List 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);
}
} elseif (switch51ConfigGateway.platformDeliveryGoodId().equals(goods.getGoodsId())) {
// 平台配送商品特殊处理
if (validatePlatformDeliveryGoods(goods, shopInfo)) {
ServiceProgramDTO program = buildPlatformDeliveryProgram(goods, shopInfo);
programs.add(program);
}
} elseif (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));
} elseif (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 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());
}
} elseif (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())) {
returnfalse;
}
// 区域校验逻辑内嵌
List allowedCities = goods.getAllowedCities();
if (!allowedCities.contains(shopInfo.getCity())) {
returnfalse;
}
// 品类校验逻辑内嵌
List allowedCategories = goods.getAllowedCategories();
if (!allowedCategories.contains(shopInfo.getCategoryId())) {
returnfalse;
}
returntrue;
}
// 类似的重复方法还有:
// validatePlatformDeliveryGoods()
// validateSelfDeliveryGoods()
// buildSuperClientProgram()
// buildPlatformDeliveryProgram()
// buildSelfDeliveryProgram()
问题点:
重构后实现
实现特点:
核心实现逻辑:
@Override
public SingleResponse
queryConfirmableProgramList(ConfirmableProgramQuery query){
// step.1 获取门店信息 - 门店上下文
ShopDomain shopDomain = shopDomainService
.getShop(query.getShopId());
// step.2 查询可签合同列表 - 合同上下文
List 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);
}
问题点:
优势:
详细改进对比
重构前核心问题点
1)重复代码泛滥
2)业务逻辑耦合
3)扩展性差
2、重复代码模式识别
问题:帮我对比下queryConfirmableProgramList 和 queryConfirmableProgramList 这两个方法链路中的代码重复度。
通过代码分析,发现以下重复代码模式:
商品类型判断逻辑重复
在以下10个文件中发现相同的判断逻辑:
重复代码示例:
// 在多个文件中重复出现的商品类型判断逻辑
if (switch51ConfigGateway.superClientGoodId().equals(goods.getGoodsId())) {
// 超客商品特殊处理逻辑
// 这段逻辑在10个不同文件中重复出现
}
重复出现的文件:
buildDeliveryProgramTypeEnum方法重复
该方法在2个类中完全重复:
重复代码消除效果
3、新增服务商品改动点对比
问题:综合上面的分析,帮我对比下v61和v6两个代码链路在新增一个服务商品时的改动点。
改动点对比总结
五、AI架构升级总结
1、AI架构升级价值和效果
1)核心价值
2)实施要点
3)实际效果
2、AI架构升级总结展望
AI辅助架构升级证明了人机协作的有效性,让工程师从重复编码中解放,专注于架构设计和业务创新。这将成为软件工程的新常态。
作者丨借势
来源丨公众号:阿里云开发者(ID:ali_tech)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
如果字段的最大可能长度超过255字节,那么长度值可能…
只能说作者太用心了,优秀
感谢详解
一般干个7-8年(即30岁左右),能做到年入40w-50w;有…
230721