《领域驱动设计精简版》读书笔记(3)——面向深层理解的重构

持续重构

重构是不改变应用行为而重新设计代码以让它变得更好的过程，重构通常是非常谨慎的，按照小幅可控的步骤进行，以确保不破坏原有的功能和引入某些缺陷，通过自动化测试可以有效保障重构的代码质量。基于某些重构模式的自动化重构工具可以让重构变得更加容易。还有另一种类型的重构，跟领域和它的模型相关，有时我们会对领域有新的理解，这让有些事物变得更清晰，或者两个元素间的关系被发现。所有的这些会通过重构被包括到设计中。让拥有表现力的代码更易读和理解是非常重要的。通过阅读代码，我们可能不光了解代码是什么，同时了解它为什么要这样。只有这样才能让代码真正捕获模型的主旨。建模步骤：

1. 关于建模的第一件事是阅读业务规范，从中寻找名词和动词。名词被转换成类，而动词则成为方法。这是一种简化，将产生浅层次的模型。
2. 所有的模型开始时都缺乏深度，但我们可以面向越来越深的理解来重构模型。这要求设计必须灵活，僵硬的设计很难做重构。

突显关键概念

当我们跟领域专家交谈时，我们交互了很多的思想和知识。某些概念成为了通用语言，但也有些一直未被重视。它们是隐式概念，用来解释以及在领域中的其他的概念。在精化设计的过程中，某些隐式概念吸引了我们注意力。我们发现它们当中的某些在设计中担当了重要的角色。因此我们需要将这些概念显式化。我们应该为它们建立类和关系。当它们发生时，我们就拥有了突破的机会。

有时设计的部分可能不会那么清晰，一堆关系会让路径的计算变得难以进行，或者计算的过程会复杂到难以理解。这在设计中显得极其笨拙，但这也是寻找隐藏的概念的绝佳之所，可能我们错过了什么。如果某个关键概念在破解谜团时缺失了，其他的事物就不得不替代它完成它的功能。这会让某些对象变胖，给它们增加了一些本不应该属于它的行为。设计的清晰度受到了破坏。努力寻找是否有缺失的概念，如果找到一个，就把它显式化。

在让概念显式化时，还有其他一些非常有用的概念：约束、过程和规约。约束是一个很简单的表示不变量的方式。无论对象的数据发生了何种变化，都要考虑不变量。这可以简单地通过把不变量的逻辑放置在一个约束中去实现它。下面是一个简单的案例，其目的是为了解释这个概念，而不是为了表现对相似案例的建议方法。

我们可以向一个书架添加书籍，但是我们永远不能增加超过它容量的部分。过程通常在代码中被表现为 procedure。从我们开始使用面向对象语言后我们就不再用一个过程化的方法，所以我们需要为过程选择一个对象，然后给它增加行为。最好的实现过程的方式是使用服务。

通过规约也可以将概念显式化，规约可以用来测试一个对象是否满足特定的条件。领域层包含了应用到实体和值对象上的业务规则。那些规则通常与它们要应用到的对象合成一体。在这些规则中，某些只是用来回答“是”和“否”的一组问题的，某些规则可以被表现成一系列操作布尔值的逻辑上的操作，最终结果也是一个布尔值。

一个这样的案例是在一个客户对象上执行测试，看它是否符合特定的信用条件。这个规则可以被表现成一个方法，起名叫 isEligible()，并且可以附加到客户对象上。但这个规则不是严格基于客户的数据进行操作的一个简单的方法。评估规则涉及到验证客户的信用，检查他过去是否支付过他的债务，检查他是否具有足够的余额等。这样的业务规则可能非常的大，非常复杂，让对象的功能肿胀，不再满足其原始的目的。在这种情况下我们可能会试图将整个规则移动到应用层，因为它看上去已经超越了领域层了。实际上，到了重构的时候了。规则应该被封装到一个负责它的对象中，这将成为客户的规约，并且被保留在领域层中。新的对象将包含一系列布尔方法，这些方法用来测试一个客户对象是否符合某种信用。每一个方法担负了一个小的测试的功能，所有的方法可以通过组合对某个原始问题给出答案。如果业务规则不能被包含到一个规约对象中，对应的代码会遍布到无数的对象中，让它不再一致。规约用来测试对象是否满足某种需要，或者他们是否已经为某种目的准备完毕。它也可以被用来从一个集合中筛选一个特定的对象，或者作为某个对象的创建条件。通常情况下，一个单个的规约负责检查是否满足一个简单的规则，若干个这样的规约组合在一起表现一个复杂的规约。