DDD思考之一 ubiquitous language

对DDD，之前看过info的mini book，也看过jdon上很多帖子，javaeye上的好像倒不是很多。一直对一些地方想不通，google的结果也是千奇百怪，想想干脆看看Eric Evans原书吧，就去卓越上买了本（本来是在当当下单的，那个物流...不说了）。 应该说Evans这书是真正写给作项目的人看的，很多地方讲的蛮细，读来受益颇深。

今天先说说ubiquitous language

这个ubiquitous language中文好像是翻作“通用语言”，我觉得倒不如google机器翻出的“无处不在的语言”更能表意。一个项目时间长了（>5 year）后，CR越来越多，业务范围越来越广，同于相同的概念，往往会有不同的称呼，而相近的称呼却往往有不同的意思。

比如我们现在作的项目，同样的品相class叫作Item，BA却有人叫SKU，有人叫Item，文档里也是两个名称混杂使用。同样是入库/出库，package叫作gate in/gate out，后来为了照顾美国人的习惯又都改称receiving/shipping，可package name和以前的代码都没有改。于是每个新人进来都要纠结一下。

再比如包装单位，其实有两种意义。一个是箱/包 这样的literal concept，另一个是指某种具体的item可以有箱/包这样的包装单位。前者在代码中叫作uom，后者在代码中叫unit of measue。可BA在文档和平时的表述中往往两者混用，需要developer自己去反应。这样的事对于新的developer来说往往是不方便甚至容易出错的。

ubiquitous language强调的就是开发环节中的各角色对于术语有着相同的认知，长期来讲这样会节省大量的沟通成本。即使不使用DDD，这点也是很有指导意义的。比如上面举的例子，随着需求的变更，更换了术语的表述，那么原来系统中相应的名称就应该rename，而不仅仅是更改UI上的文字。这样能更好的保持系统一致性。

再比如某个模块开发完了后，发现数据库中的column拼错了，把profit拼成了proift，这个错误可能已经蔓延到系统中去（除了ORMapping，可能还会有其它database level query和 SP)。发现这个错误后是不是应该修改呢？我觉得即使有代价还是应该修改。因为对以后的维护者来说,profit是一个不言自明的知识，而proift这样错误的拼写总需要一次次错误教育才能得到，这个代价是相当大的。更何况这样的知识点不可能显示的标注出来（实际上，真在注释中写上这个也只能让阅读者觉得S13）。所以站在系统的角度来说这样的坑一定要填上，相信有接手过别人代码的兄弟一定都能明白这点。

所以ubiquitous language不是对DDD才有意义的概念，它是对以往开发中一些bad practise经过总结得出的。即使对于广大的SSH用户也很有借鉴作用。

当然，也许使用DDD才能够使这种一致性达到更高的程度，这就是另外一个话题了。