我们给出了一些可以用来创建有效模型的技术指南。模型现在已经跟它所源自的领域紧密关联了。我们也已经说过代码设计应该围
绕模型展开，模型自身也会基于设计决定而有所增进。脱离了模型的设计会导致软件不能反映它所服务的领域，甚至可能得不到期
望的行为。建模如果得不到设计的反馈或者缺少了开发人员的参与，会导致必须实现模型的人很难理解它，并且可能对所用的技术
不太适合。

在设计和开发过程中，我们需要一次次得停下来，查看代码。这意味着到了重构的时间了。重构是不改变应用行为而重新设计代码以
让它更好的过程。重构通常是非常谨慎的，按照小幅且可控的步骤进行，这样我们就不会破坏功能或者引入某些bug 了。毕竟，重构
的目的是让代码更好而不是更坏。自动化测试可以为我们确保未破坏任何事情提供很大的帮助。

代码重构有很多种方式，甚至存在重构模式。这些模式描述了一个重构的自动化方法。有些基于这些模式的工具可以让开发人员的生
活比以前更容易，缺少了那些工具的支持，重构起来会非常困难。这类重构更多处理的是代码和它的质量。还有另一种类型的重构，
跟领域和它的模型相关。有时会对领域有新的理解，有些事物变得更清晰，或者两个元素间的关系被发现。所有的这些会通过重构被
包括到设计中。让拥有表现力的代码更易读和理解是非常重要的。通过阅读代码，我们可能不光了解代码是什么，同时了解它为什么
要这样。只有这样才能让代码真正捕获模型的主旨。

基于模式的技术性重构，可以被组织并结构化。面向更深层理解不能按照同样的方式进行。我们不能为它创建模式。模型的复杂性和
模型的多变性不可能提供让我们按照机械化的方式进行建模的方式。一个好的模型产生于深层的思考、理解、经验和才能。
我们被教教授的关于建模的第一件事是阅读业务规范，从中寻找名词和动词。名词被转换成类，而动词则成为方法。这是一种简化，
将产生浅层次的模型。所有的模型开始时都缺乏深度，但我们可以面向越来越深的理解来重构模型。

设计必须灵活，僵硬的设计很难做重构。头脑中若没有对代码建立灵活性的概念，那么这样的代码就会很难维护。当需要发生变化
时，你会看到代码与你交锋，会在原本应该很容易重构的事情上花费很多的时间。

使用经过验证的基础构造元素并使用一致的语言将给开发工作带来成效。这会减少不良模型所带来的挑战，我们可以捕获到领域专家
非常关心的内容，并且以此来驱动实际的设计。一个忽略表面内容且捕捉到本质内涵的模型是一个深层模型。这会让软件更加和领域
专家的思路合拍，也更能满足用户的需要。

从传统意义上讲，重构描述的是从技术动机的代码转换。重构同样可以由对领域的深入理解，以及对模型及其代码表达进行相应的精
化所推动。

除非使用迭代的重构过程，加上领域专家和开发人员一起密切关注。