11. 使用领域语言编程

使用领域语言编程

        贴两段代码，一个里面看到这：

	Map<int, Map<int, int>> if (portfolioIdsByTraderId.get(trader.getId()) .containsKey(portfolio.getId())) {...}

        你开始抓头了，想知道这句代码可能是做什么的。它像是从一个trader对象中得到ID，用这个ID从一个，呃，像是map的map中得到一个map，然后看内部的map中是否存在另一个从portfolio对象中得到的ID。你抓头抓得更厉害了。寻找portfolioIdsByTraderId的声明，发现：

	Map<int, Map<int, int>> portfolioIdsByTraderId;

        渐渐你意识到这可能是看一个trader是否能访问一个特定的portfolio。当然，在关系到一个trader是否能访问一个特定的portfolio时，你也会看到类似的代码段，或者更可能是类似但又有些细微差别的代码段。
        另一个里面你看到：

	Map<int, Map<int, int>> if (trader.canView(portfolio)) {...}

         不用抓头。你根本就不用知道一个trader里面有些什么。也许里面有个这样的map的map，但那只和trader有关，和你没关系。
现在，你更愿同这两个之中的哪个代码库打交道呢？
        曾几何时，我们只有非常基础的数据结构：位、字节和字符（实质上是字节，但我们更倾向于认为它们是字母和符号）。十进制比较难办，因为我们基于10的数字不能很好地用二进制表示，于是有了几种特定大小的浮点型。接下来就有了数组和字符串（实际上是另一种数组）。接着有了堆栈、队列、散列、链表、跳跃表等很多其它的令人兴奋的数据结构，这些在我们真实的世界中都不存在。“计算机科学”就是在把真实世界映射到有限的数据结构中花费了大量的精力。真正的大师甚至都能记住它们是怎么实现的。
然后我们有了自定义的类型！嗯，这不是什么新鲜玩意，但是它确实在某种程度上改变了游戏。如果你的领域含有像trader和portfolio这样的概念，可以用Trader和Portfolio这样的类型为其建模。但是，比这更重要的是，你可以使用领域术语为它们之间的关系建模。
        如果你不使用领域术语编程，就会造成理解时含糊不清：这个int意思是标识一个trader，那个int意思是标识一个portfolio。（最好别把它们弄混了！）如果你用一段算法片段，说的是一个map中的key的存在关系，来表达一个商业概念（“一些trader不允许查看一些portfolio——这是非法的”），那么不会给检查和审核的人任何帮助。
        接下来的程序员可能不知道这个，所以为什么不把它写清楚明白呢？通过使用一个key查找另一个key来作一个存在性检查是非常不明了的。凭什么认为可以通过直觉知道，这是在实现防止商业利益冲突的规则？
        在你的代码中使用直白的领域概念，意味着其他程序员可以更容易了解代码的意图，而不用通过尝试通过对算法的改进使之适应自己对领域的理解。这也意味着领域可以进化，随着你对领域的理解增加，你可以很方便地改进代码。加上良好的封装，规则更可能只出现在一个地方，这样你就可以更改它而不用修改任何依赖代码，这再明智不过了。
        在几个月之后负责这些代码的程序员会感谢你。在几个月之后的这个程序员也可能就是你自己。

原文：Code in the Language of the Domain byDan North