1. 为什么测试机的业务对象总像“死”的做了几年半导体测试相关的软件我一直有个特别明显的感受测试机的业务对象十有八九都是“死”的。什么意思就是那些围绕测试机开发的软件里所谓TestProgram、TestItem、Lot、SiteStatus这些“业务对象”本质都是数据容器满屏getter/setter业务逻辑全被掏空扔到Service层里用几百行if else拼出来。你做功能的时候什么都不用懂CRUD一把梭做完就完事。可产品经理一旦说要加一条业务规则——比如“某种产品在某个测试机的某个Site上测出来不通过要自动把整个Lot停住”——你会瞬间发现改代码的复杂度远超预期因为那条规则根本不属于任何一个对象它被分散在三个Service、两个Util工具类里。这就是典型的贫血模型。而真正“活”的业务对象是有灵魂的。它像现实世界里的测试设备一样有自己的状态、行为、规则。你把一个测试程序丢给它它会校验参数合法性、检查测试项是否重复、判断当前机台是否空闲还会在测量值异常时主动触发一个“结果异常”事件。这样的对象代码洁癖看了会舒服很多因为业务规则长在它该长的地方而不是飘在外面。DDDDomain-Driven Design领域驱动设计解决的就是这个问题。它的核心不是画UML图也不是定义一堆Repository和Factory而是让业务对象重新拥有行为和规则。很多人在网上吐槽“ddd搞不懂”不是概念有多难而是没有找对一个足够复杂的真实业务场景去落地。恰好半导体测试机系统就是最适合DDD的场景之一因为它的业务对象之间的关系密、规则多、状态杂数据驱动的写法到了这里基本寸步难行。这篇文章不打算从领域驱动设计的教科书理论讲起而是结合我实际参与测试机软件系统建模的经验从“业务对象为什么僵死”开始顺着DDD的落地路径一直到六边形架构、防腐层、事件驱动这些实操细节完整拆一遍我是怎么让测试机业务对象“活”过来的。适合正在半导体测试、封测工厂系统、设备自动化软件领域做开发的朋友也适合那些在别的复杂业务系统里用过DDD但始终“搞不懂”怎么落地的人。2. 先诊断测试机业务对象僵死的三个典型病灶2.1 病灶一数据库表结构直接变成类结构最常见的建模方式一张表对应一个实体类一列对应一个字段。我刚进这个行业时接手过一个测试程序管理系统TestProgram表、TestItem表、TestParam表三张表三个类外键关系变成类之间的引用逻辑简单直接。但问题在于这张表和真实业务世界是脱节的。就拿测试程序来说真实世界里一个TestProgram是什么它是一组有执行顺序、有条件分支、有参数嵌套、有Bin映射的测试流程集合。93K测试机上一个程序里一道测试项可以引用前置条件、后处理动作、多个测量参数甚至包含循环、跳转这些结构。这些结构存储在数据库里可能是几十行、几百行带父子关系的数据。如果用表驱动建模类结构就会退化成一张表的形状嵌套关系被迫用外键集合表达。写业务的时候全是“先查A表的List再循环查B表、C表”代码里全是对象图的组装逻辑。真正跟业务规则相关的东西比如“这个测试项为什么被跳过”“这个Bin对应哪个产品等级”根本无处安放。DDD的思路是让类结构主动去匹配业务世界的形状而不是被动匹配数据库表。测试程序就是一个聚合根它内部可以包含一个复杂的测试项树每个测试项有自己的参数对象参数对象里还能嵌套参数列表。这套对象结构在内存里就是活的可以直接执行业务逻辑而不是一个只有外键集合的僵尸实体。2.2 病灶二Service层承载了所有业务规则贫血模型伴随的另一个表现就是Service无敌大。什么校验逻辑、状态流转、规则判断、结果计算全塞在Service里。我见过一个TestingService四千多行里面十几个public方法方法里是层层叠叠的if判断和一个又一个的for循环注释几乎等于零因为改的人根本来不及写注释。这种事其实每个人都能理解。业务规则“放哪儿”在没有约束的时候自然是放在调用方最方便。开发提测单的时候临时加一个参数校验放进Service吧现场反馈良率异常排查逻辑顺手也放进Service吧。时间一长Service成了业务规则的垃圾桶对象模型只剩皮囊。DDD对这种问题的解法非常“偏执”凡是业务规则必须放回领域对象内部。TestProgram自己会校验失败率、会禁止被删、会计算一次执行的预期周期TestItem自己会判断是否满足执行条件、会根据测量值映射BinLot自己会管理状态不允许从Running直接跳到Closed。这些规则放进对象内部之后Service只做编排和协调不负责业务判断臃肿的问题自然解决。2.3 病灶三生产环境里的“隐性规则”无处表达很多规则根本不在代码里而在生产一线工程师的脑子里。比如同一个Lot在同一个Tester上两个相邻Site不允许同时跑同一个TestItem做并行冒烟测试因为电流会互相干扰再比如某型号产品用的测试程序版本必须在某个版本之后原因是探针台和测试机之间存在已知的配合bug。这类规则在旧系统里最常出现在什么地方运维文档、邮件、Excel表或者某条写死在报表SQL里的WHERE条件。如果业务对象是活的这类规则就应该成为聚合内部的不变量Invariant——违反它领域模型直接拒绝操作。没有DDD这类规则就永远是游离的写着写着就丢了。3. 让业务对象活过来聚合、值对象与限界上下文3.1 怎么识别聚合根别被表结构带偏做DDD建模第一步不是画图而是把业务“事件”拉出来。我惯用的方法是把测试流程从头到尾走一遍把每一件会发生的事列出来测试程序上传程序版本发布批次分批批次排程机台分配程序加载到机台开始执行测试测量值回传Bin判定结果回写良率统计设备报警程序变更一个事件就是一个业务行为。然后把这些事件背后牵涉的对象沿出来自然能得到一组概念TestProgram测试程序TestItem测试项TestParameter测试参数BinMappingBin映射Tester机台Site测试工位Lot批次Wafer晶圆Die裸芯片MeasurementResult测量结果Recipe配方概念有了接下来就是要判断各自的身份和归属。判断聚合根的核心标准只有一个有没有独立生命周期。TestItem没有独立生命周期它永远存在于TestProgram内部程序发布之前可以增删发布之后只能整体变更版本。所以它是TestProgram聚合内部的实体不能单独被外部引用。TestParameter没有身份它的参数属于某个测试项换成别的产品、别的测试项参数意义就完全不同。所以它是值对象Value Object。Lot有独立生命周期从进入测试区到测试完成它始终是唯一被跟踪的对象。Tester也有独立生命周期它的状态在一天里会从空闲到占用、到故障、到维护。所以至少可以分出三个聚合根TestProgram包含TestItem、TestParameterLot包含Wafer、Die的测试批次信息Tester包含Site状态注意我刻意没有把MeasurementResult作为聚合根——它更像是一个事件产生的结果快照用值对象表达足够给它一个全局身份反而会导致无意义的复杂性。3.2 限界上下文别让一个模型管所有事很多DDD落地方案“搞不懂”问题出在所有业务塞进一个模型里。测试机系统里至少有这几个上下文程序管理域管的是程序的上传、版本、校验、发布测试执行域管的是批次排程、机台调度、测试执行、实时结果结果分析域管的是良率统计、失效分析、SPC监控这三个上下文里的语义完全不同。同样是“Bin”在程序管理域它是一个映射配置在测试执行域它是实时判定结果在结果分析域它是良率数据里的一个分类维度。如果我强制让它们用同一个Bin对象这个对象会被各种互相矛盾的规则拉扯最后变成一堆if else。正确的做法是三个上下文各自建模型上下文之间通过翻译层转换。程序管理域里的BinMapping在测试执行域里被转换成ExecutionBin执行结果里的BinCode到分析域里又变成BinGroup。多写几个转换方法但换来的是每个模型都干净、清晰。3.3 充血模型的雏形一个带行为的TestProgram说了半天理论直接上代码。用Java做一个简单但“活”的TestProgram聚合根public class TestProgram { private ProgramId id; private String programName; private Version version; private TestItemSet items; private ProgramStatus status; // DRAFT, VALIDATED, RELEASED, RETIRED public TestProgram(ProgramId id, String name, Version version) { this.id id; this.programName name; this.version version; this.items new TestItemSet(); this.status ProgramStatus.DRAFT; } public void addTestItem(TestItem newItem) { // 业务规则同一个程序里测试项编号不能重复 if (items.containsId(newItem.getItemId())) { throw new DuplicateTestItemException(newItem.getItemId()); } // 业务规则不能给已发布的程序新增测试项必须先创建新版本 if (status ProgramStatus.RELEASED || status ProgramStatus.VALIDATED) { throw new ProgramFrozenException(id, status); } items.add(newItem); // 状态回退程序内容变了之前的校验结果作废 if (status ProgramStatus.VALIDATED) { status ProgramStatus.DRAFT; } } public void release() { // 业务规则发布前必须校验所有测试项参数完整 if (!items.isParameterComplete()) { throw new ParameterIncompleteException(id); } // 业务规则发布前必须有至少一个合法 BinMapping 配置 if (!items.hasValidBinMapping()) { throw new MissingBinMappingException(id); } this.status ProgramStatus.RELEASED; } }看到没有这个对象的行为是完整的。外部调用方不需要知道“新增测试项时要不要检查重复”“发布前要校验什么”这些规则就长在对象内部谁调用都一样躲都躲不掉。以前那种写法是这样的// 贫血模型的写法规则在Service里 public void addTestItem(Long programId, TestItemDTO dto) { TestProgramDO programDo programMapper.selectById(programId); ListTestItemDO items itemMapper.selectByProgramId(programId); for (TestItemDO item : items) { if (item.getItemCode().equals(dto.getItemCode())) { throw new DuplicateItemException(); } } if (programDo.getStatus() ProgramStatus.RELEASED) { throw new ProgramFrozenException(); } itemMapper.insert(dto.toDo()); }表面上两种写法都能完成功能但第一种有个决定性的差别Service调用方可以在不知道任何规则的情况下完成任务规则被封装在对象内部不会因为换了个人写代码而丢。这就是“业务对象活过来”的核心体验。4. 六边形架构让测试机业务对象不受外部SDK绑架4.1 为什么测试机系统必须做架构隔离做测试机软件开发最头疼的一个点是你没法脱离设备厂商的SDK做开发。93K有93K的一套APIUltraFlex有UltraFlex的一套APIJ750又是另一套。这些SDK里充满了自己的概念比如Level、Timing、PinGroup、Pattern、Flow等跟业务模型纠缠在一起之后业务代码会被SDK污染得面目全非。举个例子一个TestProgram在你的领域模型里是一个有生命周期、有业务规则的对象。但在93K的SDK眼里它是一串配置文件的集合是几十个参数文件的打包。如果你让领域模型直接依赖SDK的Program类那你自己的“程序发布”“程序校验”规则就全跟厂商的实现绑死了。这种耦合一旦建立就很难拆后面想兼容另一个机台平台等于数据库表结构大改。**六边形架构Hexagonal Architecture**解决的就是这个隔离问题。核心思想很简单领域模型在最内层不依赖任何外部技术外部系统通过“端口Port”接入端口定义接口适配器Adapter实现这些接口把外部世界的语言翻译成领域世界的语言。4.2 端口定义测试执行域的典型抽象在测试执行域我通常会定义这样几个端口public interface TesterExecutionPort { LoadResult loadProgram(TesterId testerId, ProgramCode code, Version version); ExecutionHandle startExecution(LotId lotId, ExecutionSpec spec); void pause(ExecutionHandle handle); void resume(ExecutionHandle handle); void abort(ExecutionHandle handle); ListMeasurementResult collectResults(ExecutionHandle handle, SiteId siteId); } public interface LotRepositoryPort { Lot findById(LotId lotId); void save(Lot lot); void updateStatus(LotId lotId, LotStatus status); }TesterExecutionPort就是对外部设备的“语言翻译层”。领域层定义自己关心的动作loadProgram、startExecution、collectResults至于底层是93K的API还是跟别的设备厂商提供的API领域层完全不用关心。适配器在运行时被注入进来。再看内核里的使用方式Service public class ExecutionOrchestrator { private final TesterExecutionPort testerExecution; private final LotRepositoryPort lotRepository; public ExecutionResult runLot(LotId lotId, ProgramId programId) { Lot lot lotRepository.findById(lotId); // 领域规则批次当前状态必须是 WAITING才能执行 lot.startExecution(); // 调用外部端口执行测试 ExecutionHandle handle testerExecution.startExecution(lotId, new ExecutionSpec(programId, lot.getWaferCount())); // 收集结果转成领域模型 ListMeasurementResult results testerExecution.collectResults(handle, siteId); // 更新批次内的 Die 判定状态 lot.assignResults(results); lotRepository.save(lot); return lot.getResult(); } }整段代码里完全没有出现厂商SDK的痕迹。它依赖的是自己领域里的Lot、ProgramId、MeasurementResult外部设备只是一个被端口抽象掉的“黑盒”。这就是六边形架构最大的价值业务对象可以安心地活在自己的世界里不被外界牵着走。4.3 防腐层厂商模型别想进入领域层六边形架构里还必须配一个关键的部件——防腐层Anti-Corruption LayerACL。防腐层的职责比普通适配器更重一层它不仅要翻译接口还要隔离两个模型之间的语义污染。93K的SDK里有一个概念叫“TLevel”它是一个时间参数。但你的领域模型里可能根本不需要TLevel这个概念业务上更关心的是“这个测试项的标准执行时间低于某个值”。如果不做防腐层SDK的TLevel会从代码里渗透出来——某个临时需求一旦要读TLevel开发顺手就在领域模型里加了一个字段以后想清理就难了。好的做法是在防腐层里做转换public class Tester93KAdapter implements TesterExecutionPort { private final TesterSdk93K sdk; Override public ExecutionHandle startExecution(LotId lotId, ExecutionSpec spec) { Program93K program sdk.loadProgram(spec.getProgramCode(), spec.getVersion()); LotContext93K context buildLotContext(lotId); Job93K job sdk.submitJob(program, context); return new ExecutionHandle(job.getId(), job.getState()); } }领域层拿到的是自己的StartExecution结果它不认识93K的Job不认识TLevel不认识PinMap。所有厂商概念都在适配器内部消化。这层翻译代码写起来可能有些繁琐但它保护了整个领域模型的纯度。后期就算从93K切到UltraFlex适配器重写领域层一行不动。4.4 和DDD的关系不是可选是落地标配经常有人问“六边形架构和ddd到底什么关系”。我的看法是DDD解决了领域建模问题但如果没有架构保护建好的模型会被技术细节一点点蚕食回来。六边形架构是DDD落地的最常见搭档但不是唯一搭档你也可以用分层架构只要保证领域层在最核心、不依赖外部技术的位置。实际项目中我一般这样划分内层领域模型聚合根、值对象、领域服务应用层编排用例流程负责事务边界和权限校验端口层接口抽象比如Repository、外部系统端口适配器层实现端口包括数据库Repository实现、设备SDK适配器、MES接口适配器基础设施数据库、消息队列、缓存、设备通信组件这样分下来依赖关系永远是向内的。领域层什么都不导入它只靠接口和纯Java对象完成业务逻辑。测试机厂商SDK哪怕发布了新版本、变化翻天覆地领域模型依然是稳的。这种安全感是代码洁癖做架构设计时最有价值的东西。5. 聚合内外部的事务与事件别让规则在跨对象时失灵5.1 领域服务实在放不进聚合里的规则怎么办DDD有个原则优先把规则放聚合内但如果一条规则涉及两个聚合根无法塞进任何一边就交给领域服务。测试执行域里最典型的例子是“排程分配”把某个Lot分配给某个Tester这个决策需要同时看Lot的优先级、Tester的当前负载、Site空闲情况还需要检查两个领域的不变量。这个决策不属于Lot也不完全属于Tester直接写进应用Service又会把领域规则带出去。所以我常用一个领域服务来做DomainService public class SchedulingService { public void allocate(Lot lot, Tester tester, Clock clock) { // Lot 侧规则批次不能重复分配 lot.assertAllocatable(); // Tester 侧规则机台必须有足够空闲 Site tester.assertCapacityFor(lot.getRequiredSites()); // 双方状态同步更新交给调用方控制事务 lot.allocateTo(tester.getTesterId(), clock); tester.allocate(lot.getRequiredSites()); } }这个类虽然叫Service但它操作的都是领域对象规则依然封装在对象内部领域服务只负责跨对象的规则编排。关键差异在于——这个Service知道业务规则而不是只负责把数据传来传去。5.2 领域事件测试完成不是终点而是起点业务对象“活”起来的另一个标志是它会在关键时刻发出领域事件Domain Event通知其他上下文发生的事。事件比同步调用的优势在于它让聚合之间解耦规则可以在事件处理器里完成而不用改发出事件的聚合。在测试机系统里过度使用事件是最常见的坑。有的团队走极端连一个测量点变化都发事件结果半夜一条消息在RabbitMQ里堆积几百万消费不过来最后宁可把事件机制下线。我也栽过一次这个坑——当时为了追求“松耦合”把“测试项开始执行”“测试项结束”“一个Die测完”“一个Site完成”全部事件化结果排查问题时根本追不出来龙去脉。用得正确的领域事件一定要选择那些真正有业务价值、会触发后续动作的事件。我的选择标准是如果这个事件没人感兴趣就不发。实际落地中我保留下面这组事件TestProgramReleased程序发布触发批次排程试算LotExecutionStarted批次开工触发设备加载程序LotExecutionCompleted批次完成触发良率统计与放行判定AbnormalYieldDetected良率异常触发Hold批次与告警仍以Lot执行为例事件发布逻辑写在聚合里public void assignResults(ListMeasurementResult results) { // 把测量结果写到 Die 上更新 Bin 判定 for (MeasurementResult r : results) { Die die wafers.findDie(r.getDieCoordinate()); die.applyMeasurement(r); } // 业务规则如果有效良率低于阈值批次状态置为 HOLD double yield wafers.calculateYield(); if (yield this.yieldThreshold this.status LotStatus.RUNNING) { this.hold(Yield below threshold: yield); addEvent(new AbnormalYieldDetected(this.id, yield)); } // 如果全部完成发出完成事件 if (wafers.isAllTested()) { this.complete(); addEvent(new LotExecutionCompleted(this.id, this.binStatistics)); } }事件是在聚合的方法里产生的但发布动作由应用层或基础设施负责聚合内只是把事件挂到自己的“待发布列表”里。这样聚合的代码测试很方便单测时直接调方法然后断言事件列表里有什么不需要真的连MQ。5.3 事务边界不是所有东西都在一个事务里DDD里经常被误解的一句话是“聚合内强一致聚合间最终一致”。有人一听“最终一致”就以为可以随便乱发消息、等异步处理结果数据错乱到没法收拾。但真正的问题在于很多场景明明需要强一致偏偏被拆成了最终一致。在我的项目里有一条原则同一个限界上下文内的写操作尽量走一个事务跨上下文的协同才走事件。比如“批次开工”这个动作要同时更新Lot状态、Tester状态、创建执行记录这三个对象其实都在测试执行上下文里那就老老实实一个事务做完不要拆成三个事务再靠消息去对账。反观“批次完成”和“良率统计”就是跨上下文一个在执行域一个在分析域这时候用事件驱动就更合理——执行域保证批次状态更新成功并发布事件分析域拿到事件再做统计。即便统计失败了也可以重放事件补救不会回滚已经正确完成的生产动作。6. 聚合粒度与性能的平衡测试机场景特有的几个坑6.1 别再让TestProgram聚合根加载上千个测试项理论上你的寄存器域模型设计得很美好TestProgram包含所有TestItemTestItem又有所有Parameter而且只要有集合就是List随便遍历。但半导体测试程序真实的规模是什么一台93K上的量产程序测试项都是几千道起步一个测试项往往还要带几组温度、多组参数配置。如果你每次都整根加载一次服务端请求要把几万个对象从数据库里捞出来组装性能直接爆炸。这里就需要在DDD的“纯模型”和工程现实之间做取舍。我的做法是给TestProgram聚合作细分一个聚合根对应一个“版本”TestItem以懒加载模式访问业务操作分两类结构编辑类操作新增测试项、修改参数加载骨架 当前操作的项执行发布类操作校验、发布才真正加载全量测试项在基础设施层用Repository的专用查询方法支持这些场景public interface TestProgramRepository { OptionalTestProgram findSkeletonById(ProgramId id); OptionalTestProgram findFullByIdForValidation(ProgramId id); OptionalTestItem findItemById(ProgramId id, TestItemId itemId); }领域逻辑不因为这些查询方式而改变只是基础设施层额外提供了不同的加载策略。DDD从来不是让你放弃性能而是让你在保证领域模型完整性的前提下合理选择加载路径。6.2 值对象不是摆设但也犯不着走火入魔值对象Value Object是DDD里的重要概念它没有身份、不可变、靠值相等。在测试机领域最典型的值对象就是坐标DieCoordinate、Bin判定BinDecision、测量读数MeasurementReading。把它们设成值对象代码读起来会非常有业务感public record BinDecision(int binCode, BinCategory category) { public static BinDecision of(int binCode) { return new BinDecision(binCode, categorize(binCode)); } private static BinCategory categorize(int binCode) { if (binCode 1) return BinCategory.PASS; if (binCode 2 binCode 9) return BinCategory.FAIL; return BinCategory.RETEST; } }但我也见过一个团队因为代码洁癖走火入魔把Prioriy、SiteNumber、WaferId全变成值对象最后发现代码里到处是新对象构造和equals实现开发速度肉眼可见地下降。值对象的选择标准应该是如果不是靠值相等来判定同一个东西或者不会频繁对比就别硬做成值对象。比如TestItem里面某个参数的单位用一个枚举或者String足够没必要为它单独建一个ParameterUnit类。6.3 ORM映射和领域模型结合时的脏读陷阱JPA这类ORM框架和DDD有天然的张力。实体类的集合属性被Hibernate代理后可能在你没注意时触发懒加载值对象用record实现时Hibernate映射又不一定好用。我在项目里踩过一个大坑用JPA映射一个聚合聚合内的集合属性用cascade ALL结果在批量更新测试程序版本时不小心把所有历史测试项全部级联删除了。还好当时是在测试环境生产环境出这种事就是重大事故。之后我在测试机系统里做了几条硬性规则聚合内的集合属性禁止直接暴露给外部进行增删操作所有修改必须通过聚合根方法Repository实现内部可以使用ORM但对外只暴露领域对象不暴露任何ORM实体批量写操作不要走ORM级联用批量SQL或者专门的BatchRepository处理效果非常直接业务代码里再也没有人敢绕过聚合根去操作集合了以前那种“查出列表、删掉几条、再插入几条”的写法在代码审查时直接打回。7. 从93K到全厂系统DDD价值的一次完整复盘7.1 改造前全厂系统里各说各话的“测试程序”我负责过的项目除了93K的测试程序管理还包括更上层的全厂测试管理系统类似MES和测试设备之间的中间层。系统需要统一管理多台测试机的程序、批次、结果供不同车间的工程师使用。改造之前系统里有一个叫TestProgram的实体但它的含义在不同子模块里竟然不一样。程序管理模块里它是“一套配置文件”批次调度模块里它变成“一个可执行的编号”结果分析模块里它又被当成“一条产品型号记录”。各说各话的结果就是同样是release操作程序管理模块做的是“改状态为已发布”批次调度模块做的是“把数据同步给设备”结果分析模块做的是“没法执行因为缺少产品规格信息”。三个模块三个Service三个逻辑分支幸好各管各的不然早就乱成一锅粥。用DDD做重构的第一步就是给“TestProgram”重新定位。在限界上下文梳理之后我保留了测试程序管理上下文里的TestProgram聚合根然后新增了测试执行上下文里的LoadableProgram可加载到设备的程序以及结果分析上下文里的ProgramProfile程序画像。三个模型各自独立但通过防腐层做转换核心的TestProgram领域规则得到保护。7.2 改造后一个核心用例带来的体感差异变化最大的用例是“发布测试程序”。老逻辑出差错最多的地方是发布前没人能确定程序里的测试项参数是否完整、Bin映射是否有效、是否存在重复项。改造后的新逻辑长这样// 应用层编排调用方不需要了解内部规则 public ProgramReleaseResponse releaseProgram(ProgramId id) { TestProgram program programRepository.findFullByIdForValidation(id); program.release(); // 聚合根自校验规则 programRepository.save(program); // 持久化状态 publisher.publish(new TestProgramReleased(id, program.getVersion())); return ProgramReleaseResponse.from(program); }没改多少代码但规则归属变了。因为是聚合根方法执行释放操作所有业务规则都能在单元测试里覆盖到。测试程序发布这种高风险操作我从原来靠人工Checklist核对变成了单测保证状态机约束出问题的概率大幅下降。代码洁癖看到这种变化应该是很舒服的——你不需要再依赖某个人“记得”检查参数完整性因为规则在代码里就永远存在。7.3 性能与模型的最终并存有人会担心引入DDD和六边形架构会让系统变慢。实际运行下来性能瓶颈反而不在领域层——一次发布操作耗时从80ms增加到120ms主要开销是领域校验逻辑和对象映射完全可接受。真正耗时的还是网络通信和设备接口而这些都隔离在适配器层领域模型的调整不会影响它们。我的经验是不要用百分之几的性能损耗去换取业务资产的清晰度。测试机领域的业务资产是极其值钱的——测试方法、判定规则、良率模型这些才是产线真正的know-how。让它们被结构良好的代码承载比省几个毫秒有意义得多。8. 落地实操经验从哪切入、怎么验证、如何避坑8.1 第一个DDD试点模块怎么选很多团队学完DDD想做的第一件事就是把整个系统用DDD重写一遍。这个冲动我非常理解但现实是全量重写风险极高工期不可控还会影响产线稳定。我建议反过来选一个边界清晰、规则密集、改动频繁的孤岛模块先试点。我见过最合适的试点模块就是测试程序管理。它的业务对象边界相对清楚程序、项、参数规则多且敏感发布校验、版本控制外部依赖相对少主要就是程序和数据库适合团队先熟悉DDD的开发节奏。做完这个模块团队基本能积累一套自己的DDD落地规范再往批次调度、结果分析这些复杂场景推进就顺很多。8.2 领域建模的工作坊怎么开才有效所谓“ddd搞不懂”很多时候是建模工作坊开得有问题。事件风暴不能一次拉几十个人必须是核心业务专家加开发小范围分轮做。我一般这样组织第一轮只列业务事件谁都不许聊技术第二轮给事件排顺序找聚合根候选第三轮挑聚合根做不变量分析写业务规则清单第四轮把规则翻译成代码草稿验证是否可以放进聚合前三轮花四五个小时第四轮可能花一周。如果你的工作坊一轮就产出几十张Event和十几个Aggregate那大概率没有真正吃透业务后面代码里肯定到处是洞。8.3 测试策略领域层单测是最后防线DDD做的再好没有测试保护也等于零。我写测试机领域模型时的单测策略大致如下测试对象覆盖重点示例场景聚合根状态机状态是否合法流转DRAFT → VALIDATED → RELEASED禁止 RELEASED 直接回到 DRAFT聚合不变量规则是否被强制执行已发布程序禁止新增测试项、批次不能重复分配值对象相等判断、工厂方法Bin 码映射分类是否正确领域服务跨聚合编排规则Lot 与 Tester 的容量校验端口适配器翻译是否准确SDK 返回的 Job 状态转换是否正确单测跑得飞快几百个用例几秒钟跑完。每次改领域代码几十秒内就能知道有没有破坏规则。这种感觉比我早期写贫血模型时强太多——那时候改一条规则要手动连数据库跑一遍流程还不敢保证所有路径都被测到。9. 现在做测试机系统的DDD还能用上哪些新思路9.1 事件溯源与CQRS适合结果分析域的进阶选项测试机系统天然适合CQRS和事件溯源的场景不是执行域而是结果分析域。测量结果一旦产生就不变这是天然的不可变事件流。如果采用事件溯源把每一次测试完成的结果作为事件存储良率统计、失效分析这些查询可以直接从事件流中重建各种维度不需要维护一张巨大的事实表。但我的建议是先别全量上。事件溯源的成本比普通持久化高很多存储量增加、查询复杂、事件版本兼容都要处理。可以让结果分析域先用CQRS读取侧单独建投影表写入侧保持现状效果提升就很明显。事件溯源则等团队有足够经验之后再小范围试点。9.2 DDD与测试程序的“配置即代码”结合测试程序领域还有个新趋势就是把测试程序配置本身用代码描述进入Git仓库管理。一个TestProgram聚合根不再只是数据库里的记录它可以映射为一个Git仓库、一个分支、一个Tag。程序发布动作在领域模型里是一个状态变更在基础设施层可能对应一次git tag创建。这种模式让程序版本管理和日常开发的版本管理统一起来。领域模型仍然负责业务规则校验程序是否完整、参数是否有效技术设施负责版本控制分支、Tag、历史。两者通过六边形架构的端口隔离配合得很干净。代码洁癖应该会喜欢这种方案——业务演进和技术管理各自归位谁也不越界。9.3 测试机系统的DDD体验总结写了这么多说到底就是一句话业务对象“活”起来的前提是把业务规则交还给对象本身然后用六边形架构守护这个对象不被外部世界破坏。在我自己的代码洁癖审美里最舒服的代码不是那些用了多少设计模式的而是每次接到新需求能直接找到一个现成的对象去增加一个行为而不是去某个Service里翻修两千行逻辑。半导体测试机的业务足够复杂也足够有价值值得用DDD这套思路认真打磨。从一个试点模块开始让业务先在你自己的代码里“活”起来后面整个系统都会跟着慢慢醒过来。
让业务对象活起来：DDD在半导体测试机系统中的落地实践
1. 为什么测试机的业务对象总像“死”的做了几年半导体测试相关的软件我一直有个特别明显的感受测试机的业务对象十有八九都是“死”的。什么意思就是那些围绕测试机开发的软件里所谓TestProgram、TestItem、Lot、SiteStatus这些“业务对象”本质都是数据容器满屏getter/setter业务逻辑全被掏空扔到Service层里用几百行if else拼出来。你做功能的时候什么都不用懂CRUD一把梭做完就完事。可产品经理一旦说要加一条业务规则——比如“某种产品在某个测试机的某个Site上测出来不通过要自动把整个Lot停住”——你会瞬间发现改代码的复杂度远超预期因为那条规则根本不属于任何一个对象它被分散在三个Service、两个Util工具类里。这就是典型的贫血模型。而真正“活”的业务对象是有灵魂的。它像现实世界里的测试设备一样有自己的状态、行为、规则。你把一个测试程序丢给它它会校验参数合法性、检查测试项是否重复、判断当前机台是否空闲还会在测量值异常时主动触发一个“结果异常”事件。这样的对象代码洁癖看了会舒服很多因为业务规则长在它该长的地方而不是飘在外面。DDDDomain-Driven Design领域驱动设计解决的就是这个问题。它的核心不是画UML图也不是定义一堆Repository和Factory而是让业务对象重新拥有行为和规则。很多人在网上吐槽“ddd搞不懂”不是概念有多难而是没有找对一个足够复杂的真实业务场景去落地。恰好半导体测试机系统就是最适合DDD的场景之一因为它的业务对象之间的关系密、规则多、状态杂数据驱动的写法到了这里基本寸步难行。这篇文章不打算从领域驱动设计的教科书理论讲起而是结合我实际参与测试机软件系统建模的经验从“业务对象为什么僵死”开始顺着DDD的落地路径一直到六边形架构、防腐层、事件驱动这些实操细节完整拆一遍我是怎么让测试机业务对象“活”过来的。适合正在半导体测试、封测工厂系统、设备自动化软件领域做开发的朋友也适合那些在别的复杂业务系统里用过DDD但始终“搞不懂”怎么落地的人。2. 先诊断测试机业务对象僵死的三个典型病灶2.1 病灶一数据库表结构直接变成类结构最常见的建模方式一张表对应一个实体类一列对应一个字段。我刚进这个行业时接手过一个测试程序管理系统TestProgram表、TestItem表、TestParam表三张表三个类外键关系变成类之间的引用逻辑简单直接。但问题在于这张表和真实业务世界是脱节的。就拿测试程序来说真实世界里一个TestProgram是什么它是一组有执行顺序、有条件分支、有参数嵌套、有Bin映射的测试流程集合。93K测试机上一个程序里一道测试项可以引用前置条件、后处理动作、多个测量参数甚至包含循环、跳转这些结构。这些结构存储在数据库里可能是几十行、几百行带父子关系的数据。如果用表驱动建模类结构就会退化成一张表的形状嵌套关系被迫用外键集合表达。写业务的时候全是“先查A表的List再循环查B表、C表”代码里全是对象图的组装逻辑。真正跟业务规则相关的东西比如“这个测试项为什么被跳过”“这个Bin对应哪个产品等级”根本无处安放。DDD的思路是让类结构主动去匹配业务世界的形状而不是被动匹配数据库表。测试程序就是一个聚合根它内部可以包含一个复杂的测试项树每个测试项有自己的参数对象参数对象里还能嵌套参数列表。这套对象结构在内存里就是活的可以直接执行业务逻辑而不是一个只有外键集合的僵尸实体。2.2 病灶二Service层承载了所有业务规则贫血模型伴随的另一个表现就是Service无敌大。什么校验逻辑、状态流转、规则判断、结果计算全塞在Service里。我见过一个TestingService四千多行里面十几个public方法方法里是层层叠叠的if判断和一个又一个的for循环注释几乎等于零因为改的人根本来不及写注释。这种事其实每个人都能理解。业务规则“放哪儿”在没有约束的时候自然是放在调用方最方便。开发提测单的时候临时加一个参数校验放进Service吧现场反馈良率异常排查逻辑顺手也放进Service吧。时间一长Service成了业务规则的垃圾桶对象模型只剩皮囊。DDD对这种问题的解法非常“偏执”凡是业务规则必须放回领域对象内部。TestProgram自己会校验失败率、会禁止被删、会计算一次执行的预期周期TestItem自己会判断是否满足执行条件、会根据测量值映射BinLot自己会管理状态不允许从Running直接跳到Closed。这些规则放进对象内部之后Service只做编排和协调不负责业务判断臃肿的问题自然解决。2.3 病灶三生产环境里的“隐性规则”无处表达很多规则根本不在代码里而在生产一线工程师的脑子里。比如同一个Lot在同一个Tester上两个相邻Site不允许同时跑同一个TestItem做并行冒烟测试因为电流会互相干扰再比如某型号产品用的测试程序版本必须在某个版本之后原因是探针台和测试机之间存在已知的配合bug。这类规则在旧系统里最常出现在什么地方运维文档、邮件、Excel表或者某条写死在报表SQL里的WHERE条件。如果业务对象是活的这类规则就应该成为聚合内部的不变量Invariant——违反它领域模型直接拒绝操作。没有DDD这类规则就永远是游离的写着写着就丢了。3. 让业务对象活过来聚合、值对象与限界上下文3.1 怎么识别聚合根别被表结构带偏做DDD建模第一步不是画图而是把业务“事件”拉出来。我惯用的方法是把测试流程从头到尾走一遍把每一件会发生的事列出来测试程序上传程序版本发布批次分批批次排程机台分配程序加载到机台开始执行测试测量值回传Bin判定结果回写良率统计设备报警程序变更一个事件就是一个业务行为。然后把这些事件背后牵涉的对象沿出来自然能得到一组概念TestProgram测试程序TestItem测试项TestParameter测试参数BinMappingBin映射Tester机台Site测试工位Lot批次Wafer晶圆Die裸芯片MeasurementResult测量结果Recipe配方概念有了接下来就是要判断各自的身份和归属。判断聚合根的核心标准只有一个有没有独立生命周期。TestItem没有独立生命周期它永远存在于TestProgram内部程序发布之前可以增删发布之后只能整体变更版本。所以它是TestProgram聚合内部的实体不能单独被外部引用。TestParameter没有身份它的参数属于某个测试项换成别的产品、别的测试项参数意义就完全不同。所以它是值对象Value Object。Lot有独立生命周期从进入测试区到测试完成它始终是唯一被跟踪的对象。Tester也有独立生命周期它的状态在一天里会从空闲到占用、到故障、到维护。所以至少可以分出三个聚合根TestProgram包含TestItem、TestParameterLot包含Wafer、Die的测试批次信息Tester包含Site状态注意我刻意没有把MeasurementResult作为聚合根——它更像是一个事件产生的结果快照用值对象表达足够给它一个全局身份反而会导致无意义的复杂性。3.2 限界上下文别让一个模型管所有事很多DDD落地方案“搞不懂”问题出在所有业务塞进一个模型里。测试机系统里至少有这几个上下文程序管理域管的是程序的上传、版本、校验、发布测试执行域管的是批次排程、机台调度、测试执行、实时结果结果分析域管的是良率统计、失效分析、SPC监控这三个上下文里的语义完全不同。同样是“Bin”在程序管理域它是一个映射配置在测试执行域它是实时判定结果在结果分析域它是良率数据里的一个分类维度。如果我强制让它们用同一个Bin对象这个对象会被各种互相矛盾的规则拉扯最后变成一堆if else。正确的做法是三个上下文各自建模型上下文之间通过翻译层转换。程序管理域里的BinMapping在测试执行域里被转换成ExecutionBin执行结果里的BinCode到分析域里又变成BinGroup。多写几个转换方法但换来的是每个模型都干净、清晰。3.3 充血模型的雏形一个带行为的TestProgram说了半天理论直接上代码。用Java做一个简单但“活”的TestProgram聚合根public class TestProgram { private ProgramId id; private String programName; private Version version; private TestItemSet items; private ProgramStatus status; // DRAFT, VALIDATED, RELEASED, RETIRED public TestProgram(ProgramId id, String name, Version version) { this.id id; this.programName name; this.version version; this.items new TestItemSet(); this.status ProgramStatus.DRAFT; } public void addTestItem(TestItem newItem) { // 业务规则同一个程序里测试项编号不能重复 if (items.containsId(newItem.getItemId())) { throw new DuplicateTestItemException(newItem.getItemId()); } // 业务规则不能给已发布的程序新增测试项必须先创建新版本 if (status ProgramStatus.RELEASED || status ProgramStatus.VALIDATED) { throw new ProgramFrozenException(id, status); } items.add(newItem); // 状态回退程序内容变了之前的校验结果作废 if (status ProgramStatus.VALIDATED) { status ProgramStatus.DRAFT; } } public void release() { // 业务规则发布前必须校验所有测试项参数完整 if (!items.isParameterComplete()) { throw new ParameterIncompleteException(id); } // 业务规则发布前必须有至少一个合法 BinMapping 配置 if (!items.hasValidBinMapping()) { throw new MissingBinMappingException(id); } this.status ProgramStatus.RELEASED; } }看到没有这个对象的行为是完整的。外部调用方不需要知道“新增测试项时要不要检查重复”“发布前要校验什么”这些规则就长在对象内部谁调用都一样躲都躲不掉。以前那种写法是这样的// 贫血模型的写法规则在Service里 public void addTestItem(Long programId, TestItemDTO dto) { TestProgramDO programDo programMapper.selectById(programId); ListTestItemDO items itemMapper.selectByProgramId(programId); for (TestItemDO item : items) { if (item.getItemCode().equals(dto.getItemCode())) { throw new DuplicateItemException(); } } if (programDo.getStatus() ProgramStatus.RELEASED) { throw new ProgramFrozenException(); } itemMapper.insert(dto.toDo()); }表面上两种写法都能完成功能但第一种有个决定性的差别Service调用方可以在不知道任何规则的情况下完成任务规则被封装在对象内部不会因为换了个人写代码而丢。这就是“业务对象活过来”的核心体验。4. 六边形架构让测试机业务对象不受外部SDK绑架4.1 为什么测试机系统必须做架构隔离做测试机软件开发最头疼的一个点是你没法脱离设备厂商的SDK做开发。93K有93K的一套APIUltraFlex有UltraFlex的一套APIJ750又是另一套。这些SDK里充满了自己的概念比如Level、Timing、PinGroup、Pattern、Flow等跟业务模型纠缠在一起之后业务代码会被SDK污染得面目全非。举个例子一个TestProgram在你的领域模型里是一个有生命周期、有业务规则的对象。但在93K的SDK眼里它是一串配置文件的集合是几十个参数文件的打包。如果你让领域模型直接依赖SDK的Program类那你自己的“程序发布”“程序校验”规则就全跟厂商的实现绑死了。这种耦合一旦建立就很难拆后面想兼容另一个机台平台等于数据库表结构大改。**六边形架构Hexagonal Architecture**解决的就是这个隔离问题。核心思想很简单领域模型在最内层不依赖任何外部技术外部系统通过“端口Port”接入端口定义接口适配器Adapter实现这些接口把外部世界的语言翻译成领域世界的语言。4.2 端口定义测试执行域的典型抽象在测试执行域我通常会定义这样几个端口public interface TesterExecutionPort { LoadResult loadProgram(TesterId testerId, ProgramCode code, Version version); ExecutionHandle startExecution(LotId lotId, ExecutionSpec spec); void pause(ExecutionHandle handle); void resume(ExecutionHandle handle); void abort(ExecutionHandle handle); ListMeasurementResult collectResults(ExecutionHandle handle, SiteId siteId); } public interface LotRepositoryPort { Lot findById(LotId lotId); void save(Lot lot); void updateStatus(LotId lotId, LotStatus status); }TesterExecutionPort就是对外部设备的“语言翻译层”。领域层定义自己关心的动作loadProgram、startExecution、collectResults至于底层是93K的API还是跟别的设备厂商提供的API领域层完全不用关心。适配器在运行时被注入进来。再看内核里的使用方式Service public class ExecutionOrchestrator { private final TesterExecutionPort testerExecution; private final LotRepositoryPort lotRepository; public ExecutionResult runLot(LotId lotId, ProgramId programId) { Lot lot lotRepository.findById(lotId); // 领域规则批次当前状态必须是 WAITING才能执行 lot.startExecution(); // 调用外部端口执行测试 ExecutionHandle handle testerExecution.startExecution(lotId, new ExecutionSpec(programId, lot.getWaferCount())); // 收集结果转成领域模型 ListMeasurementResult results testerExecution.collectResults(handle, siteId); // 更新批次内的 Die 判定状态 lot.assignResults(results); lotRepository.save(lot); return lot.getResult(); } }整段代码里完全没有出现厂商SDK的痕迹。它依赖的是自己领域里的Lot、ProgramId、MeasurementResult外部设备只是一个被端口抽象掉的“黑盒”。这就是六边形架构最大的价值业务对象可以安心地活在自己的世界里不被外界牵着走。4.3 防腐层厂商模型别想进入领域层六边形架构里还必须配一个关键的部件——防腐层Anti-Corruption LayerACL。防腐层的职责比普通适配器更重一层它不仅要翻译接口还要隔离两个模型之间的语义污染。93K的SDK里有一个概念叫“TLevel”它是一个时间参数。但你的领域模型里可能根本不需要TLevel这个概念业务上更关心的是“这个测试项的标准执行时间低于某个值”。如果不做防腐层SDK的TLevel会从代码里渗透出来——某个临时需求一旦要读TLevel开发顺手就在领域模型里加了一个字段以后想清理就难了。好的做法是在防腐层里做转换public class Tester93KAdapter implements TesterExecutionPort { private final TesterSdk93K sdk; Override public ExecutionHandle startExecution(LotId lotId, ExecutionSpec spec) { Program93K program sdk.loadProgram(spec.getProgramCode(), spec.getVersion()); LotContext93K context buildLotContext(lotId); Job93K job sdk.submitJob(program, context); return new ExecutionHandle(job.getId(), job.getState()); } }领域层拿到的是自己的StartExecution结果它不认识93K的Job不认识TLevel不认识PinMap。所有厂商概念都在适配器内部消化。这层翻译代码写起来可能有些繁琐但它保护了整个领域模型的纯度。后期就算从93K切到UltraFlex适配器重写领域层一行不动。4.4 和DDD的关系不是可选是落地标配经常有人问“六边形架构和ddd到底什么关系”。我的看法是DDD解决了领域建模问题但如果没有架构保护建好的模型会被技术细节一点点蚕食回来。六边形架构是DDD落地的最常见搭档但不是唯一搭档你也可以用分层架构只要保证领域层在最核心、不依赖外部技术的位置。实际项目中我一般这样划分内层领域模型聚合根、值对象、领域服务应用层编排用例流程负责事务边界和权限校验端口层接口抽象比如Repository、外部系统端口适配器层实现端口包括数据库Repository实现、设备SDK适配器、MES接口适配器基础设施数据库、消息队列、缓存、设备通信组件这样分下来依赖关系永远是向内的。领域层什么都不导入它只靠接口和纯Java对象完成业务逻辑。测试机厂商SDK哪怕发布了新版本、变化翻天覆地领域模型依然是稳的。这种安全感是代码洁癖做架构设计时最有价值的东西。5. 聚合内外部的事务与事件别让规则在跨对象时失灵5.1 领域服务实在放不进聚合里的规则怎么办DDD有个原则优先把规则放聚合内但如果一条规则涉及两个聚合根无法塞进任何一边就交给领域服务。测试执行域里最典型的例子是“排程分配”把某个Lot分配给某个Tester这个决策需要同时看Lot的优先级、Tester的当前负载、Site空闲情况还需要检查两个领域的不变量。这个决策不属于Lot也不完全属于Tester直接写进应用Service又会把领域规则带出去。所以我常用一个领域服务来做DomainService public class SchedulingService { public void allocate(Lot lot, Tester tester, Clock clock) { // Lot 侧规则批次不能重复分配 lot.assertAllocatable(); // Tester 侧规则机台必须有足够空闲 Site tester.assertCapacityFor(lot.getRequiredSites()); // 双方状态同步更新交给调用方控制事务 lot.allocateTo(tester.getTesterId(), clock); tester.allocate(lot.getRequiredSites()); } }这个类虽然叫Service但它操作的都是领域对象规则依然封装在对象内部领域服务只负责跨对象的规则编排。关键差异在于——这个Service知道业务规则而不是只负责把数据传来传去。5.2 领域事件测试完成不是终点而是起点业务对象“活”起来的另一个标志是它会在关键时刻发出领域事件Domain Event通知其他上下文发生的事。事件比同步调用的优势在于它让聚合之间解耦规则可以在事件处理器里完成而不用改发出事件的聚合。在测试机系统里过度使用事件是最常见的坑。有的团队走极端连一个测量点变化都发事件结果半夜一条消息在RabbitMQ里堆积几百万消费不过来最后宁可把事件机制下线。我也栽过一次这个坑——当时为了追求“松耦合”把“测试项开始执行”“测试项结束”“一个Die测完”“一个Site完成”全部事件化结果排查问题时根本追不出来龙去脉。用得正确的领域事件一定要选择那些真正有业务价值、会触发后续动作的事件。我的选择标准是如果这个事件没人感兴趣就不发。实际落地中我保留下面这组事件TestProgramReleased程序发布触发批次排程试算LotExecutionStarted批次开工触发设备加载程序LotExecutionCompleted批次完成触发良率统计与放行判定AbnormalYieldDetected良率异常触发Hold批次与告警仍以Lot执行为例事件发布逻辑写在聚合里public void assignResults(ListMeasurementResult results) { // 把测量结果写到 Die 上更新 Bin 判定 for (MeasurementResult r : results) { Die die wafers.findDie(r.getDieCoordinate()); die.applyMeasurement(r); } // 业务规则如果有效良率低于阈值批次状态置为 HOLD double yield wafers.calculateYield(); if (yield this.yieldThreshold this.status LotStatus.RUNNING) { this.hold(Yield below threshold: yield); addEvent(new AbnormalYieldDetected(this.id, yield)); } // 如果全部完成发出完成事件 if (wafers.isAllTested()) { this.complete(); addEvent(new LotExecutionCompleted(this.id, this.binStatistics)); } }事件是在聚合的方法里产生的但发布动作由应用层或基础设施负责聚合内只是把事件挂到自己的“待发布列表”里。这样聚合的代码测试很方便单测时直接调方法然后断言事件列表里有什么不需要真的连MQ。5.3 事务边界不是所有东西都在一个事务里DDD里经常被误解的一句话是“聚合内强一致聚合间最终一致”。有人一听“最终一致”就以为可以随便乱发消息、等异步处理结果数据错乱到没法收拾。但真正的问题在于很多场景明明需要强一致偏偏被拆成了最终一致。在我的项目里有一条原则同一个限界上下文内的写操作尽量走一个事务跨上下文的协同才走事件。比如“批次开工”这个动作要同时更新Lot状态、Tester状态、创建执行记录这三个对象其实都在测试执行上下文里那就老老实实一个事务做完不要拆成三个事务再靠消息去对账。反观“批次完成”和“良率统计”就是跨上下文一个在执行域一个在分析域这时候用事件驱动就更合理——执行域保证批次状态更新成功并发布事件分析域拿到事件再做统计。即便统计失败了也可以重放事件补救不会回滚已经正确完成的生产动作。6. 聚合粒度与性能的平衡测试机场景特有的几个坑6.1 别再让TestProgram聚合根加载上千个测试项理论上你的寄存器域模型设计得很美好TestProgram包含所有TestItemTestItem又有所有Parameter而且只要有集合就是List随便遍历。但半导体测试程序真实的规模是什么一台93K上的量产程序测试项都是几千道起步一个测试项往往还要带几组温度、多组参数配置。如果你每次都整根加载一次服务端请求要把几万个对象从数据库里捞出来组装性能直接爆炸。这里就需要在DDD的“纯模型”和工程现实之间做取舍。我的做法是给TestProgram聚合作细分一个聚合根对应一个“版本”TestItem以懒加载模式访问业务操作分两类结构编辑类操作新增测试项、修改参数加载骨架 当前操作的项执行发布类操作校验、发布才真正加载全量测试项在基础设施层用Repository的专用查询方法支持这些场景public interface TestProgramRepository { OptionalTestProgram findSkeletonById(ProgramId id); OptionalTestProgram findFullByIdForValidation(ProgramId id); OptionalTestItem findItemById(ProgramId id, TestItemId itemId); }领域逻辑不因为这些查询方式而改变只是基础设施层额外提供了不同的加载策略。DDD从来不是让你放弃性能而是让你在保证领域模型完整性的前提下合理选择加载路径。6.2 值对象不是摆设但也犯不着走火入魔值对象Value Object是DDD里的重要概念它没有身份、不可变、靠值相等。在测试机领域最典型的值对象就是坐标DieCoordinate、Bin判定BinDecision、测量读数MeasurementReading。把它们设成值对象代码读起来会非常有业务感public record BinDecision(int binCode, BinCategory category) { public static BinDecision of(int binCode) { return new BinDecision(binCode, categorize(binCode)); } private static BinCategory categorize(int binCode) { if (binCode 1) return BinCategory.PASS; if (binCode 2 binCode 9) return BinCategory.FAIL; return BinCategory.RETEST; } }但我也见过一个团队因为代码洁癖走火入魔把Prioriy、SiteNumber、WaferId全变成值对象最后发现代码里到处是新对象构造和equals实现开发速度肉眼可见地下降。值对象的选择标准应该是如果不是靠值相等来判定同一个东西或者不会频繁对比就别硬做成值对象。比如TestItem里面某个参数的单位用一个枚举或者String足够没必要为它单独建一个ParameterUnit类。6.3 ORM映射和领域模型结合时的脏读陷阱JPA这类ORM框架和DDD有天然的张力。实体类的集合属性被Hibernate代理后可能在你没注意时触发懒加载值对象用record实现时Hibernate映射又不一定好用。我在项目里踩过一个大坑用JPA映射一个聚合聚合内的集合属性用cascade ALL结果在批量更新测试程序版本时不小心把所有历史测试项全部级联删除了。还好当时是在测试环境生产环境出这种事就是重大事故。之后我在测试机系统里做了几条硬性规则聚合内的集合属性禁止直接暴露给外部进行增删操作所有修改必须通过聚合根方法Repository实现内部可以使用ORM但对外只暴露领域对象不暴露任何ORM实体批量写操作不要走ORM级联用批量SQL或者专门的BatchRepository处理效果非常直接业务代码里再也没有人敢绕过聚合根去操作集合了以前那种“查出列表、删掉几条、再插入几条”的写法在代码审查时直接打回。7. 从93K到全厂系统DDD价值的一次完整复盘7.1 改造前全厂系统里各说各话的“测试程序”我负责过的项目除了93K的测试程序管理还包括更上层的全厂测试管理系统类似MES和测试设备之间的中间层。系统需要统一管理多台测试机的程序、批次、结果供不同车间的工程师使用。改造之前系统里有一个叫TestProgram的实体但它的含义在不同子模块里竟然不一样。程序管理模块里它是“一套配置文件”批次调度模块里它变成“一个可执行的编号”结果分析模块里它又被当成“一条产品型号记录”。各说各话的结果就是同样是release操作程序管理模块做的是“改状态为已发布”批次调度模块做的是“把数据同步给设备”结果分析模块做的是“没法执行因为缺少产品规格信息”。三个模块三个Service三个逻辑分支幸好各管各的不然早就乱成一锅粥。用DDD做重构的第一步就是给“TestProgram”重新定位。在限界上下文梳理之后我保留了测试程序管理上下文里的TestProgram聚合根然后新增了测试执行上下文里的LoadableProgram可加载到设备的程序以及结果分析上下文里的ProgramProfile程序画像。三个模型各自独立但通过防腐层做转换核心的TestProgram领域规则得到保护。7.2 改造后一个核心用例带来的体感差异变化最大的用例是“发布测试程序”。老逻辑出差错最多的地方是发布前没人能确定程序里的测试项参数是否完整、Bin映射是否有效、是否存在重复项。改造后的新逻辑长这样// 应用层编排调用方不需要了解内部规则 public ProgramReleaseResponse releaseProgram(ProgramId id) { TestProgram program programRepository.findFullByIdForValidation(id); program.release(); // 聚合根自校验规则 programRepository.save(program); // 持久化状态 publisher.publish(new TestProgramReleased(id, program.getVersion())); return ProgramReleaseResponse.from(program); }没改多少代码但规则归属变了。因为是聚合根方法执行释放操作所有业务规则都能在单元测试里覆盖到。测试程序发布这种高风险操作我从原来靠人工Checklist核对变成了单测保证状态机约束出问题的概率大幅下降。代码洁癖看到这种变化应该是很舒服的——你不需要再依赖某个人“记得”检查参数完整性因为规则在代码里就永远存在。7.3 性能与模型的最终并存有人会担心引入DDD和六边形架构会让系统变慢。实际运行下来性能瓶颈反而不在领域层——一次发布操作耗时从80ms增加到120ms主要开销是领域校验逻辑和对象映射完全可接受。真正耗时的还是网络通信和设备接口而这些都隔离在适配器层领域模型的调整不会影响它们。我的经验是不要用百分之几的性能损耗去换取业务资产的清晰度。测试机领域的业务资产是极其值钱的——测试方法、判定规则、良率模型这些才是产线真正的know-how。让它们被结构良好的代码承载比省几个毫秒有意义得多。8. 落地实操经验从哪切入、怎么验证、如何避坑8.1 第一个DDD试点模块怎么选很多团队学完DDD想做的第一件事就是把整个系统用DDD重写一遍。这个冲动我非常理解但现实是全量重写风险极高工期不可控还会影响产线稳定。我建议反过来选一个边界清晰、规则密集、改动频繁的孤岛模块先试点。我见过最合适的试点模块就是测试程序管理。它的业务对象边界相对清楚程序、项、参数规则多且敏感发布校验、版本控制外部依赖相对少主要就是程序和数据库适合团队先熟悉DDD的开发节奏。做完这个模块团队基本能积累一套自己的DDD落地规范再往批次调度、结果分析这些复杂场景推进就顺很多。8.2 领域建模的工作坊怎么开才有效所谓“ddd搞不懂”很多时候是建模工作坊开得有问题。事件风暴不能一次拉几十个人必须是核心业务专家加开发小范围分轮做。我一般这样组织第一轮只列业务事件谁都不许聊技术第二轮给事件排顺序找聚合根候选第三轮挑聚合根做不变量分析写业务规则清单第四轮把规则翻译成代码草稿验证是否可以放进聚合前三轮花四五个小时第四轮可能花一周。如果你的工作坊一轮就产出几十张Event和十几个Aggregate那大概率没有真正吃透业务后面代码里肯定到处是洞。8.3 测试策略领域层单测是最后防线DDD做的再好没有测试保护也等于零。我写测试机领域模型时的单测策略大致如下测试对象覆盖重点示例场景聚合根状态机状态是否合法流转DRAFT → VALIDATED → RELEASED禁止 RELEASED 直接回到 DRAFT聚合不变量规则是否被强制执行已发布程序禁止新增测试项、批次不能重复分配值对象相等判断、工厂方法Bin 码映射分类是否正确领域服务跨聚合编排规则Lot 与 Tester 的容量校验端口适配器翻译是否准确SDK 返回的 Job 状态转换是否正确单测跑得飞快几百个用例几秒钟跑完。每次改领域代码几十秒内就能知道有没有破坏规则。这种感觉比我早期写贫血模型时强太多——那时候改一条规则要手动连数据库跑一遍流程还不敢保证所有路径都被测到。9. 现在做测试机系统的DDD还能用上哪些新思路9.1 事件溯源与CQRS适合结果分析域的进阶选项测试机系统天然适合CQRS和事件溯源的场景不是执行域而是结果分析域。测量结果一旦产生就不变这是天然的不可变事件流。如果采用事件溯源把每一次测试完成的结果作为事件存储良率统计、失效分析这些查询可以直接从事件流中重建各种维度不需要维护一张巨大的事实表。但我的建议是先别全量上。事件溯源的成本比普通持久化高很多存储量增加、查询复杂、事件版本兼容都要处理。可以让结果分析域先用CQRS读取侧单独建投影表写入侧保持现状效果提升就很明显。事件溯源则等团队有足够经验之后再小范围试点。9.2 DDD与测试程序的“配置即代码”结合测试程序领域还有个新趋势就是把测试程序配置本身用代码描述进入Git仓库管理。一个TestProgram聚合根不再只是数据库里的记录它可以映射为一个Git仓库、一个分支、一个Tag。程序发布动作在领域模型里是一个状态变更在基础设施层可能对应一次git tag创建。这种模式让程序版本管理和日常开发的版本管理统一起来。领域模型仍然负责业务规则校验程序是否完整、参数是否有效技术设施负责版本控制分支、Tag、历史。两者通过六边形架构的端口隔离配合得很干净。代码洁癖应该会喜欢这种方案——业务演进和技术管理各自归位谁也不越界。9.3 测试机系统的DDD体验总结写了这么多说到底就是一句话业务对象“活”起来的前提是把业务规则交还给对象本身然后用六边形架构守护这个对象不被外部世界破坏。在我自己的代码洁癖审美里最舒服的代码不是那些用了多少设计模式的而是每次接到新需求能直接找到一个现成的对象去增加一个行为而不是去某个Service里翻修两千行逻辑。半导体测试机的业务足够复杂也足够有价值值得用DDD这套思路认真打磨。从一个试点模块开始让业务先在你自己的代码里“活”起来后面整个系统都会跟着慢慢醒过来。
