自从DDD被重新拉回到人们的视线之后，统一语言这个术语也越来越多得出现在不同的场合。尤其是业务人员与技术人员在沟通的时候，业务人员听不懂技术人员在讲什么，技术人员也不听业务人员讲，按照自己对世界的固有经验和假设，用一套自以为通用的语言沟通，这种沟通方式势必会趋于低效。如果没有得到有效解决，势必会造成系统的建模和业务模型不匹配，导致软件很难被人理解，一连串的破窗连锁反应就接踵而至。
有了DDD方法论的加持，人们在实践的过程中逐渐养成了统一语言的意识形态和行为习惯，在业务人员向技术人员传递业务知识的时候的丢帧率降低，很多业务语言能够被技术人员所理解和接纳，第一层沟通逐渐像统一语言靠齐了。此时你以为万事大吉了吗？其实并没有，技术人员接下来一步还是会大概率陷入自身的固有习惯中，发生屏蔽概念、遗漏概念、偷换概念、脑补概念。就拿袁帅之前整出的一个例子来说说。他对需求的进行Tasking，得到一个这样的任务：
Given 一个有空位的停车场； When 停车；Then 停车成功，返回一张票据
当他用TDD的方式去写第一个测试用例的时候，出来如下的结果：
@Test
void should_return_a_valid_ticket_when_parking_given_a_parking_lot_with_available_space(){
ParkingLot parkingLot = new ParkingLot(1);
String car = "布加迪";
String ticket = parkingLot.park(car);
assertNotNull(ticket);
}
那么这里面的car和ticket变量其实就是一种屏蔽概念的现象，命名在Task写的是票据和车，在软件建模的时候就丢失了这两个概念，直接用String类型去代表。袁帅没有统一车和票据这两个语言吗？并不是，他很清楚知道业务人员关于这两个属于的含义。他可能就是一个基本类型偏执狂而已。
概念的丢失，软件系统建模和业务建模的不匹配，势必会造成代码的可理解性降低，袁帅的图省事会增加别人的理解难度。
经过一轮调整，袁帅后来写出了这样的代码：
@Test
void should_return_a_valid_ticket_when_parking_given_a_parking_lot_with_available_space(){
ParkingLot parkingLot = new ParkingLot(1);
Car car = new Car("001");
Ticket ticket = parkingLot.park(car);
assertEquals(ticket.getCarNo(), "No.001");
}
public class Car {
private String id;
public Car(String id){
this.id = id;
}
}
关于袁帅调整后的结果，你觉得有问题吗？
网友评论