TDD + DDD 双剑合璧：我是如何用测试驱动出清晰领域模型的

TDD DDD 双剑合璧我是如何用测试驱动出清晰领域模型的当业务需求像一团迷雾般模糊不清时我们往往陷入两难要么过早陷入技术实现细节导致模型偏离业务本质要么在抽象讨论中原地打转迟迟无法产出可验证的代码。三年前我在开发电商优惠券系统时正是通过TDD与DDD的协同运用找到了破解这一困局的密钥。1. 从混沌到清晰测试作为需求探针接到优惠券使用限制需求时产品文档只有一句话不同用户等级享有不同折扣力度。传统做法可能是立即设计Coupon实体和User类但TDD要求我们首先思考这个功能究竟该如何被验证我创建了第一个测试用例Test void should_reject_coupon_when_user_level_below_required() { User basicUser new User(basic); Coupon vipCoupon new Coupon().setRequiredLevel(vip); assertThrows(InvalidCouponException.class, () - vipCoupon.applyFor(basicUser)); }这个红色测试迫使我在编写实现前明确几个关键问题用户等级是简单的字符串还是需要值对象优惠券校验逻辑应该放在Coupon内部还是服务层异常类型是否需要区分不同失败场景测试即需求的特性在此显现——通过编写可执行的验证逻辑我们实际上是在用代码定义业务规则的精确表述。当测试无法轻易编写时往往意味着需求理解存在模糊地带。2. 红绿循环中的模型演进初始实现仅用20行代码就让测试变绿class Coupon { private String requiredLevel; public void applyFor(User user) { if (!user.getLevel().equals(requiredLevel)) { throw new InvalidCouponException(); } } }但重构阶段暴露出原始设计的贫血性——校验逻辑机械地比较字符串缺乏业务语义。这引导我进行以下改进将用户等级升级为值对象class UserLevel { private final int weight; public boolean canUse(CouponLevel required) { return this.weight required.getWeight(); } }引入CouponLevel领域概念enum CouponLevel { REGULAR(1), VIP(2), SVIP(3); private final int weight; // getter constructor }重构后的应用逻辑public void applyFor(User user) { if (!user.getLevel().canUse(this.requiredLevel)) { throw new InvalidCouponException(Insufficient user level); } }测试的保护网让我们能安全地进行模型深化——每次重构后运行测试确保行为不变的同时提升代码表现力。经过五轮红绿循环原本简单的字符串比较演进为具有明确业务含义的领域对象协作。3. 测试驱动出领域元素当需求扩展到限量发放时TDD自然地驱动出DDD的典型模式3.1 领域事件浮现测试用例先定义预期行为Test void should_publish_event_when_coupon_claimed() { Coupon coupon new Coupon().setTotalQuota(100); coupon.claimBy(testUser); assertTrue(coupon.domainEvents() .contains(new CouponClaimedEvent(couponId, userId))); }实现时发现需要引入领域事件机制这促使我们定义CouponClaimedEvent值对象在聚合根中添加领域事件收集机制设计轻量级的事件发布接口3.2 聚合根的明确多次测试迭代后我们意识到Coupon需要维护已发放数量的不变性发放操作必须保证事务一致性使用记录需要关联到具体用户这些认知最终固化为代码中的聚合边界class Coupon { private CouponId id; private int totalQuota; private int claimedCount; private ListUsageRecord usages; public void claimBy(User user) { if (claimedCount totalQuota) { throw new CouponExhaustedException(); } this.claimedCount; this.usages.add(new UsageRecord(user.id())); this.registerEvent(new CouponClaimedEvent(id, user.id())); } }4. 双循环开发模式经过多个需求迭代我总结出以下实践模式4.1 外层DDD循环阶段活动产出物业务探索事件风暴/用例分析限界上下文划分模型设计聚合/实体/值对象识别领域模型图实现规划确定技术实现路径模块划分/接口设计4.2 内层TDD循环业务规则测试从领域专家角度编写验收测试单元测试针对具体领域对象编写细粒度测试实现用最简单代码通过测试重构提升模型表达力保持测试通过这种双循环模式确保我们既不会过早陷入技术细节通过DDD保持业务视角也不会构建出无法验证的抽象模型通过TDD保证可执行性。5. 实战避坑指南在金融级优惠券系统开发中我们遇到几个典型问题陷阱1测试过度依赖实现细节// 反模式测试耦合内部状态 Test void bad_test_example() { coupon.claim(); assertEquals(1, coupon.getInternalCounter()); // 脆弱测试 } // 改进测试业务可见行为 Test void good_test_example() { coupon.claim(); assertFalse(coupon.isAvailable()); // 基于业务语义 }陷阱2领域服务膨胀当发现CouponService超过300行时我们通过以下手段优化将校验逻辑下移到值对象用领域事件替代过程式调用引入策略模式处理差异化规则陷阱3测试数据构建困难通过构建测试专用工厂方法解决class CouponTestBuilder { private CouponLevel level CouponLevel.REGULAR; private int quota 10; public static CouponTestBuilder newCoupon() { return new CouponTestBuilder(); } public Coupon build() { return new Coupon(level, quota); } } // 使用示例 Coupon coupon CouponTestBuilder.newCoupon() .withLevel(VIP) .withQuota(100) .build();6. 效能提升技巧技巧1测试命名即文档// 糟糕的命名 Test void testCase1() {} // 良好的命名 Test void should_apply_20percent_discount_when_user_is_vip_and_cart_over_1000() {}技巧2自定义断言提升可读性public class CouponAssert { public static void assertValidFor(Coupon coupon, User user) { if (!coupon.isApplicableFor(user)) { fail(Coupon should be valid for user.getLevel()); } } } // 使用示例 Test void check_eligibility() { CouponAssert.assertValidFor(vipCoupon, vipUser); }技巧3可视化测试报告通过Allure等工具生成包含以下信息的报告业务用例覆盖情况领域模型元素测试覆盖率业务规则验证矩阵在持续交付流水线中这些报告成为领域模型健康度的重要指标。当新增需求导致测试覆盖率下降时团队会立即收到警报并补充验证场景。