结束语

后记

虽然开发最前沿的项目并体验有趣的思想和工具会带来巨大的成就感，但我认为如果软件得不到有效的应用，那么一切都将成为空谈。事实上，检验软件成功与否的最有效的方法是让它运行一段时间。近年来，我从自己经历过的项目中总结出了一些经验。

这里我们来谈一下其中5个项目，每个项目都认真尝试了领域驱动设计，但它们并没有系统地采用这种方法，当然也没有在这个名头下进行开发。这5个项目都完成了软件交付工作，其中4个项目坚持采用模型驱动的设计方法，并得到了相应的设计结果，而有一个项目却偏离了轨道。一些应用程序多年来一直在发展和改变，但有一个程序一直没有进步，还有一个很早就结束了。

第1章中描述的PCB设计软件的beta 版本在业内引起了一次很大的轰动，但遗憾的是，发起该项目的公司在它的营销方面做得非常失败，最终公司草草收场。少数一些保留了beta版副本的PCB工程师现在仍在使用该软件。像所有缺乏支持的软件一样，它会被继续使用下去，直到其中集成的某个程序发生重大改变为止。

第9章中介绍的贷款软件在我提到的突破之后，经历了3年波澜不惊的发展。在此之后，该项目脱离出来，成为一家独立的公司。在重组的过程中，从一开始就领导这个项目的经理被解聘了，一些核心开发人员也随他一起离开。新的团队有一套稍微不同的设计思想，他们不是完全遵循对象建模。但保留了具有复杂行为的独特的领域层，而且在他们的开发团队中依旧非常重视领域知识。在新公司独立运转7年后，该软件仍在不断增加新的功能。它在业内是该领域领先的应用程序，正在为越来越多的客户机构服务，也是公司最大的收入来源。

一片新种植的橄榄林

在领域驱动方法广为流行之前，很多项目的软件将创建得更快、更高效。但项目最终仍不免按传统的套路发展，导致先前精炼的深层模型无法被充分利用，更谈不上去增强它的能力了。可能我的期望过高了，但如果做不到这一点，项目就无法在长达数年的时间内为用户提供稳定的价值。

我曾经与另一位开发人员结对做过一个项目，我们为客户编写一个实用工具，客户用这个工具来开发他们的核心产品。所需的功能及功能组合相当复杂。我很喜欢这个项目的工作，我们也开发出了一个具有ABSTRACT CORE的柔性设计。这个软件交付以后，每个人涉及的工作也就结束了。由于项目交接之后就与我们无关了，交接过程显得有些突兀，因此我估计那些用来支持元素组合的特性可能很难被客户理解，而且有可能被替换为更典型的条件选择逻辑。但这种情况并没有马上发生。当我们交付软件的时候，程序包含一个完整的测试套件和一个精炼文档。新的团队成员用这个文档来指导他们的工作。他们对这个软件做了一番研究之后，很高兴地发现我们的设计提供了各种可能性。当我在一年之后听到他们的评论时，我知道我们的UBIQUITOUS LANGUAGE已经传递到了新团队，而且这种语言仍然充满活力并继续发展。

7年之后

又一年过去了，我听到一个完全不同的故事。团队遇到了新的需求，开发人员们发现用原来的设计已经无法满足这些新需求。他们不得不修改设计，这一改几乎使原来的设计面目全非。在了解了一些细节之后，我发现我们原来的模型用来解决这些问题时显然十分蹩脚。往往就是在这个时候有可能产生一次突破，形成一个更深层的模型，特别是在这个例子中，开发人员已经积累了大量的深层领域知识和经验。事实上，他们确实形成了新的理解，并最终根据这些理解对模型和设计进行了转换。

他们小心翼翼地、委婉地告诉了我这件事情，我猜他们可能是担心我在听到如此多的先前工作被丢弃后会感到不满。但是我对自己的设计并没有这种守旧情结。一个成功的设计并不一定要永远保持不变。如果把人们赖以工作的一个系统封闭起来，那么它将会变为一项永久的、谁也不敢碰的遗留资产。深层模型可以使人们清楚地看懂它，并据此产生新的理解，而柔性设计可以促进后续的修改。他们提出了一个更深层的模型，这个模型更符合用户关心的需求。他们的设计解决了实际问题。变更是软件的固有性质，这个程序在拥有它的团队的手中得到了继续发展。

本书很多章节中都提到过运输的例子，这个例子大体上是基于一家大型国际集装箱运输公司的项目。在早期，项目的领导者们采用了领域驱动的方法，但他们一直没有建立一种支持该方法的开发文化。几支具有不同设计技术水平和对象经验的团队分头开始创建模块，但他们之间的工作只是由团队领导者之间的非正式合作和一个主要负责客户事务的架构团队来粗略地协调。我们确实开发出了一个合理的、深层的CORE DOMAIN模型，也有一个可使用的UBIQUITOUS LANGUAGE。

但公司的文化非常不利于迭代开发，因此我们过了很长时间才形成了一个可用的内部版本。因此，问题到了后期才暴露出来，而此时修复的话就要冒很大的风险并且要付出高昂的代价。我们发现模型的某些方面会引起数据库性能问题。反馈（无论是实现问题，还是模型修改）是MODEL-DRIVEN DESIGN的一个自然的部分，但那时我们感觉到自己已经在开发这条路上走得太远了，以至于很难再修改模型的基本部分了。相反，我们对代码做了修改，使它更有效，但代码与模型的联系却被削弱了。最初的版本也暴露出在技术基础设施扩展方面的局限性，这使管理层感到担忧。项目组聘请了专家来修复基础设施问题，项目恢复了开发。但实现与领域建模之间却始终没有形成一个闭环。

有几个团队交付了不错的软件——实现了复杂的功能，模型也表达得很清楚。而有些团队交付的软件却很生硬，模型退化为数据结构（尽管他们保留了UBIQUITOUS LANGUAGE的痕迹）。可能使用CONTEXT MAP会有所帮助，因为各个团队的开发结果之间没有什么必然联系。然而，用UBIQUITOUS LANGUAGE开发出来的CORE模型确实帮助团队把各自的工作整合为一个系统。

虽然范围缩小了，项目还是替换了几个遗留系统。尽管大部分设计都不够灵活，但整体设计还是通过一个共享的概念集凝聚到了一起。经过几年之后，系统本身已经退化为一项遗留资产，但它仍在为全球业务提供全天候的服务。虽然成功团队的影响渐渐扩大，但整个项目最后还是走到了尽头，即便公司有着雄厚的财力。项目文化从来没有真正采纳过MODEL-DRIVEN DESIGN。现在的新开发是在不同平台上进行的，我们的工作只是间接影响他们，因为新开发人员需要遵从（CONFORM）他们的遗留系统。

在一些领域中，像运输公司最初设定的那样宏伟的目标是不可信的。更好的做法是开发小的、确保能够交付的应用程序，并坚持用最简单的设计来实现简单的功能。这种保守的方法有它自己的用武之地，可以使项目范围保持精简，并且使项目具有快速响应的能力。但集成的、模型驱动的系统所提供的价值是那些拼凑起来的系统无法提供的。但我们还有一种方法，那就是使用领域驱动设计构建深层模型和柔性设计，这样，具有丰富功能的大型系统就能够逐步增长。

最后我们来说一下Evant，这是一家开发库存管理系统的公司，我曾在这家公司做过辅助支持的工作，也为公司已经很健壮的设计文化作出了一点贡献。有些人把这个项目看作是极限编程的典型代表，但很少有人注意到它也广泛应用了领域驱动设计。在这个项目中，模型被不断精炼，并且用更柔性的设计表达出来。这个项目在2001年的“dot com”泡沫破裂以前一直在快速发展。不过随后由于投资断流，公司一度萎缩，软件开发也基本上陷入休眠状态，看起来离倒闭的日子不远了。但在2002年夏季，Evant被一个世界排名前十的零售商看中。这家潜在的客户喜欢Evant的产品，但产品需要改变设计，以便扩展系统来支持大量库存规划操作。这是Evant的最后机会。

虽然项目人员已萎缩至4人，但团队仍然有实力。他们都具有精湛的技术，并且掌握了大量领域知识，而且其中一位成员还精通系统的扩展问题。他们有着非常高效的开发文化，代码库也实现了柔性设计，因此便于修改。在那个夏天，这4位开发人员经过艰巨的努力终于使系统能够处理数以十亿计的规划元素以及数百个用户。借助于这些强大功能，Evant赢得了这家大客户。不久之后，它被另一家公司收购，这家公司希望利用他们的软件以及他们所展示出的能力来应对新的需求。

领域驱动的设计文化（以及极限编程文化）在公司过渡期间幸存下来并获得了新生。现在，模型和设计仍在不断发展，比两年前我工作的时候要丰富和灵活得多。而且Evant团队并没有被收购它的公司同化，相反，在Evant团队成员的带动下，公司现有项目团队正在向Evant团队的开发文化转变。这个故事还远未结束。

没有哪个项目会用到本书中介绍的所有技术。尽管如此，我们很容易通过几个方面辨认出一个项目是否采用了领域驱动设计。标志性的特征是把“理解目标领域并将学到的知识融合到软件中”当作首要任务。其他工作都以它为前提。团队成员在项目中有意识地使用通用语言，并且不断对语言进行精化。由于他们不断地学习越来越多的领域知识，因此他们永远不会满足于现有领域模型的质量。他们把持续精化视作机会，把不适当的模型视作风险。他们知道，开发出高质量的、能够清晰反映出领域模型的软件并非易事，因此他们一丝不苟地运用设计技巧。他们也因为遇到障碍而跌倒过，但却始终坚持自己的原则，百折不挠，继续前进。

未来展望

气候、生态系统和生物学以前被认为是杂乱无章的，是与物理或化学恰好相反的“软”领域。然而，近来人们认识到这种“混乱”的表象实际上提出了一个具有深远意义的技术挑战，这意味着要去发现和理解这些非常复杂的现象之中蕴含的规律。当下，“复杂性”领域是众多科学的前沿。虽然有才能的软件工程师通常都认为纯粹的技术任务是最有趣、最有挑战性的，但领域驱动设计展现了一个同样富有挑战性（甚至具有更大挑战性）的新领域。业务软件大可不必是拼凑而成的杂乱系统。与复杂的领域“搏斗”，把它转化为可理解的软件设计，这对于优秀的技术人员来说是一项激动人心的挑战。

由外行创建复杂软件的时代还远未到来。虽然掌握了一些初级技术的众多编程人员可以开发出特定种类的软件，但他们绝对无法开发出能在危急关头拯救公司的软件。真正需要做的是：工具构建人员必须确保他们开发出的工具能够提高那些优秀软件开发人员的能力和工作效率。真正需要做的是：更加透彻地研究领域模型，并在可运行的软件中把它们表示出来。我非常希望能够尝试出于这个目的而设计的新工具和技术。

然而，尽管好的工具很有价值，但我们不能把注意力都放在工具上而忽视掉一个基本事实——创建好的软件是一项需要学习和思考的活动。建模需要想象力和自律。好的工具能够帮助我们思考或避免分心。企图自动实现一些只有通过思考才能完成的任务是不切实际的，如果这样做的话，产生的效果只会适得其反。

利用已有的工具和技术，我们可以开发出比当今大多数项目更有价值的系统。我们可以编写优秀的软件，这样的软件使用起来是一种乐趣，它在扩展的时候不会对我们构成限制，反而会为我们创造新的机会，并且会不断为其使用者提供价值。