我能DDD吗？

你是可以实施DDD的，如果你：

• 有开发卓越软件的激情和毅力

• 渴望学习和进步

• 有能力理解软件模式，并懂得如何应用这些模式

• 有发掘不同设计方法的能力和耐性

• 勇于改变现状

• 看重细节，希望亲自试验

• 希望编写更好的代码

DDD不是没有学习曲线，而且学习曲线有可能很陡。不用着急，本书将尽可能地为你降低学习曲线，我的目的就是挖掘你成功的潜能，帮助你和你的团队实现DDD。

DDD首先并不是关于技术的，而是关于讨论、聆听、理解、发现和业务价值的，而这些都是为了将知识集中起来。如果你了解公司的业务，那么你至少可以为DDD的通用语言（Ubiquitous Language）做出贡献。当然，你可能需要学习更多的业务知识。由于你对业务概念的理解，你已经开始走在DDD的康庄大道上了。

多年的软件开发经验能够帮助我更好地实现DDD吗？可能会。然而，你的开发经验并没有教给你向领域专家聆听和学习的能力。在实施DDD的过程中，你最好将那些不怎么使用技术语言的人加进自己的团队，此时你得仔细地聆听他们，还应该尊重他们的观点，并且相信他们比你了解得更多。

将领域专家引入到团队是大有好处的。

在实施DDD的过程中，你最好将那些不怎么使用技术语言的人加进自己的团队。就像你会向他们学习一样，他们也会向你学习。

可能你最希望看到的便是：领域专家同样得听你的。大家都是同一个团队的成员。领域专家不见得就知道所有的业务，他们也得学习。就像你会向他们学习一样，他们也会向你学习。你向领域专家提出的问题有可能暴露出他们不知道的地方。你将直接帮组团队更好地理解业务，甚至确定业务。

这样一来，团队中的所有成员都在学习和成长——是DDD使之成为了可能。

但是，我们还没有领域专家

领域专家并不是一个职位，他可以是精通业务的任何人。他们可能了解更多的关于业务领域的背景知识，他们可能是软件产品的设计者，甚至有可能是销售员。

如果你发现有人比你更加了解业务知识，找到他们，聆听他们，并向他们学习。

现在，我们已经开了一个好头。我并不是说技术不重要，而是说在本书中你得掌握领域建模中更高层次的概念。如果你的能力能够位于理解《Head First设计模式》[Freeman et al]和《设计模式》[Gamma et al]之间，或者你还学了一些更高级的模式，那么你已经具备很好的DDD基础了。在本书中，我将尽量顾及到各个层次的学习者。

什么是领域模型？

领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了准确的业务含义。

不同角色的人都可以从DDD中获益，看看自己属于以下角色的哪一种：

• 新手，初级开发者：“我还年轻，有很多点子，对写代码充满了热情。但是我所在的那个项目简直让人崩溃，我才不想一毕业就被那些重复性的工作纠来缠去。这个项目的架构为什么如此复杂？这到底是怎么呢？我修改了一点代码，却破坏了更多的代码。有人知道这本来应该是什么样子吗？现在，我还得添加一些复杂的新特性。我在遗留代码之上添加了一个适配器来屏蔽那些难看的遗留代码，但是没有用。我相信除了整天写代码和调试外，还有更好的办法。于是有人向我介绍DDD，听说DDD是领域模型中的‘四人帮（Gang of Four）’，不错不错。”

• 中级开发者：“在过去的几个月中，我加入了一个新的项目，这次轮到我来做出改变了。那时，当我和高级开发人员在一起工作时，我发现我缺少对事物的洞察力。有时团队非常涣散，但是我又不知道其中的原因，我决定改变团队成员们的做事方式。我需要一种能够助我成功的软件开发技术。一个高级架构师向我推荐DDD，我打算了解了解。

听起来你已经是个高级开发者了，继续往下读。你超前思考的态度自然会得到回报的。

• 高级开发者，架构师：“我曾在多个项目中都使用过DDD，不过目前所在项目还未使用。我喜欢DDD战术模式的威力，但是我还打算应用更多的DDD模式，比如战略设计等。在阅读[Evans]时，我发现通用语言的功能非常强大。我已经与团队成员和管理层讨论过采用DDD的事情了，但其中有些中高级开发者对DDD在项目中的前景并不看好，而管理层也不是那么热衷于DDD。我是最近才加入公司的，虽然我是团队带头人，但是整个团队似乎并不愿意被一些新奇玩意儿打断了开发进度。不管如何，我是不会放弃的。虽然其他开发者对DDD没有信心，但是我是能做到的。我决定将领域专家引入到团队中来，使他们跟技术人员一起工作。”

这就是一个领导应该做的。本书包含了很多关于战略设计的例子。

• 领域专家：“我已经在IT部门帮他们解决业务问题好长一段时间了，我希望开发者们能够更好地理解他们所做的事情。他们总是认为我们业务人员是愚蠢的。但是他们不知道的是，如果不是我们，他们早就丢了工作。开发者总会以一些奇怪的方式来讨论我们的软件，如果我说这是A，他们却说这是B，好像我们需要有本词典才能交流一样。如果我们试图纠正他们的错误叫法，他们就不愿意合作了。我们在这上面浪费了太多的时间。软件为什么不能像真正的业务专家所想象的那样工作呢？”你说对了。软件开发的最大问题之一便是业务人员和技术人员需要某种翻译才能交流。本章将对此做出讨论。你将看到，DDD将业务人员和技术人员放在同一个层面上。惊讶吧，你已经使一些开发者向你靠近了，多帮帮他们。

• 项目经理：“我们要交付软件，但结果并不总是让人舒心，有时开发时间拖得太长了。开发者在谈论到领域时总是各执一词，莫衷一是。我不确定我们是否需要另一种银弹般的技术或者方法。之前我们不是没有尝试过，但是每次都失败了，结果还是得回到原来的位置。我总是说，我们应该放弃幻想，准备战斗，但是团队成员并不这么认为。他们工作非常努力，我总觉得欠他们些什么，于是听听他们的意见吧。他们都是聪明之人，并且都希望做出些改变。对于我来说，如果我上面的管理层同意，我是完全允许开发者们花

时间学习的。团队成员们希望有个集中化的业务知识体系，我想我可以以此说服我的老板。这样一来，我自己的工作也将变得简单，我还可以促进团队和业务专家之间的合作与互信。”

多好的项目经理啊！

不管你是谁，有一点是重要的：要在DDD之路上取得成功，你肯定得学习，并且大量地学习。学习不是什么问题，你是聪明的，并且一直都在学习。然而，我们都面临这样一种困境：

就个人来讲，我时刻都在准备着学习，但是我并不喜欢被人教。

——Winston Churchill

在本书中，我会尽量将知识传递变成一件愉悦之事，并且保证你在DDD上有所收获。

你可能又有问题了：“为什么我们需要DDD呢？”