InfoQ：Eric Evans在Domain Driven Design一书中的成果，现在已经普遍被认为是DDD定义及实施的黄金标准了。而你的这本有关DDD的书是在Evans的“蓝皮书”之后过了差不多十年才出版的，为什么选择这个时间？ 如果你看看周围，我想你会发现其它一些书也在某些方面探讨了DDD。比如说，Jimmy Nilsson的书就基本是紧接着Eric Evans的书问世的。我认为Jimmy在他的书中体现了他的远见，而他的努力也为.NET社区的进步贡献良多。 我的书不同于其它书籍的一点是，它采取了一种案例学习的途径，并有意识地展现了采用DDD时最常见的各种错误，然后再揭示如何修正这些错误，或者是避免错误。这种方式至少有两点好处：首先，它通过预先指出常见的陷阱，清晰地指示读者如何避免它。对于一个软件顾问来说，最困难的一种情况是，在他进入的项目中每个人都工作很努力，但在不断地挣扎与失败，而他需要指出大家的问题所在。团队成员会本能地拒绝帮助，因为他们已经离不开他们熟悉的方式了，并坚持他们的方式会得到更好的结果。 这本书则通过一个虚构的团队指出问题，这有助于读者抛开防卫心态。他们可以任意地把自己代入这个失败中的团队，但一切只是虚构的。第二点，这本书提供了清晰的指导，如何按照尽可能最安全的方式实施DDD。通过遵循这些指导，或者说这些经验法则，采用DDD的团队就能按照最佳建议成功地实施DDD。这并不是说如果你违反了一两个规则就一定不会成功，但如果你不了解放弃这些规则的代价，你就应该遵循它。 为什么选择这个时间？在我们这个行业工作了十年或者二十年之后，有谁不认为现在是时候正视软件开发，就像开发一架飞行器一样严肃对待了呢？当然，有人会选择无视现实，而我们只能期望最好不要和他们在一个项目里共事。而当期望落空时，我们需要知道如何通过应用某些DDD实践使自己从这种混乱中脱身。所以我想说，现在正是时候。
InfoQ：在企业中实施DDD可能需要一定时间，从DDD的尝试当中，是否可以渐进式地获得某些收益？ 我认为，打算以渐进式步骤改善设计的团队可以采取两种方式齐头并进。首先采用一些策略式设计（Strategic design），决定出那些能为企业带来大价值的部分。如果你是在为一个成熟的企业（而非一个创业型公司）工作，那很可能这部分价值会与某个陈旧的遗留系统相关。使用上下文映射（Context Mapping）和子领域（subdomain）分析会帮助你理解问题的范围，指出通往解决方案的正确方向。一旦你的团队领会了这种策略方式，团队成员就能决定新业务应该在怎样的上下文边界（Bounded Context）中进行建模了。 不过有一个问题经常被提起，那就是与陈旧的遗留系统进行整合的最佳方式是什么？这里有两种主要的解决方法：如果可能的话，你可以让遗留系统发布某些关键的领域事件（Domain Event），以提示系统中的发生的事。让新的边界上下文侦听这些重要的领域事件，并对其作出响应，以实现某些系统功能。我想你总能够找到方法，从遗留系统中发布某些关键的领域事件。 不过，想把遗留系统转入一个完整的事件驱动架构（事件驱动架构）可能会有些不实际。这种情况下，找到另一种在遗留系统和新系统之间交换信息的方式就会显示出必要性了。我建议你去尝试一下这两种策略方式：开放主机服务（Open Host Service）和防护层（Anti-Corruption Layer）。虽然还存在其它的可能性，但这两者被认为是DDD整合的有效途径。 不过，要注意到我们并没有为改善遗留系统投入大量精力，我们只是渐增式地为遗留系统加入了一些钩子（hook），不用多，足够满足新系统的需要就可以了。我们也许会重写一小部分代码，但经验告诉我们，重写过程必需小心谨慎。如果不尽量减少重写，那么对遗留系统的一处小改动经常会造成严重的连锁反应，并大面积地破坏现有的测试。而要想处理所有的连锁反应不仅困难并花费精力，还会降低系统稳定性。 最后，使用DDD战术设计（tactical design）可以对边界上下文进行深度或浅度建模。使用聚合（Aggregate）很有价值，但要得到设计良好的聚合将面临许多挑战。为了确保成功，需要对“经验原则”投入大量的关注。
InfoQ：有些人被DDD吓跑，因为它有着自己的语言，非常复杂，指导手册也接近600页。DDD是真的这么难实现吗？ 是也不是。我想这主要取决于你的背景。对那些非常熟悉优秀面向对象设计的人来说，许多概念自然而然就会从头脑里跳出来。另一方面，有些人更熟悉数据库驱动的设计，在贫血模型中有着无数的getter和setter，他们就需要更多的训练了。因为他们不仅要学习新知识，还需要抛弃大量现有的观念。在这种情况下，最重要的就是看开发者作出改变的意愿了。 我的这本书会帮助以上两种人更容易在应用DDD上获得成功。我必须厚着脸皮推荐一下我的培训课程，即IDDD 培训班。我已经在整个欧洲进行了一系列的培训课程，现在已接近结束了。2013年7月22日至25日，我将在美国科罗拉多州的丹佛开讲，你可以在这里注册。
InfoQ：对于打算推行DDD的人来说，他在企业里会面对怎样的阻力呢？他又该如何克服这些阻力？ 如果你打算用DDD改变你的整个公司或者其中很大一部分，你注定要失败。无论你是否获得业务上的支持都会失败的。何况，如果你有打算改变公司中的很大部分的某种想法，你本来也很难得获得业务上的支持。我的观点里，采用DDD最大的错误是一个包含开发者和架构师的团队想做的太多，哪怕本身想法很好，但是对管理执行者来说，听到某个团队打算对现有系统作出重大影响的改变，甚至是完全重写多个系统，他一定会被吓到的。其实这不仅仅是对管理者很恐怖，对于任何一个了解如何正确使用DDD的人，或者仅是了解顺利完成这种高投入的项目的复杂性的人而言，这都很恐怖。而当DDD提倡者不断重复他们的倡议时，矛盾就更激化了。 我认为要避免业务上的阻力，最好是找到某种开销较小的方法，在一个新的边界上下文中交付实际的，重要的商业价值。第一个项目最好能够将范围控制得相对小一些，只要保证你在预算和时间计划内能正常交付就可以了。也不要把它当作一项“重大机密科研项目”来处理，因为你至少要从一位领域专家中那里分享思想。虽然你也可以把它当作地下工作来搞，但这种方式必定难以长久。因此最好计划能产生一定的影响力，同时也保持合理的期望。这就意味着你需要对你自己和其它开发者的期望加以控制。这种以商业思考方式进行思考的训练很有益，它对按照正确的方法实施DDD是非常重要的。 不要提太多倡议，保持飞行在雷达之下，不断交付，获得他人的尊敬与信任。在你交付了一两个能产生可见的商业价值的项目之后，你再基于你的成功经验，以及你对应该怎样使用及不应该怎样使用DDD的清晰见解，提出对DDD的倡议，就处于比较有利的位置了。
InfoQ：归根到底，是否所有的垂直行业都适合应用DDD呢？当系统中的其余部分的复杂性在不断提升的情况下，是否能有一部分始终保持一定程度的复杂性不变呢？ 使用DDD的最佳时机，是用以处理你的业务中最复杂的部分，以及能够带来最大商业价值的地方。这就意味着在整体业务中的某些技术部分是不值得投入DDD的。但我并不是说在这些要求较低的地方，就不必应用正确的软件开发原则，甚至某些原则还是基于DDD的。我想表示的是：即使某个系统在战略上的价值不高，也不意味着应该糟糕地实现它。即便是通用软件和支持软件，对整个端到端的解决方案的运维也有着重要意义。不过，你就不需要和领域专家做那么深度的探讨了，无需达到那些核心领域一样的程度。 团队有时会吃惊地发现，某个他们一直不重视的系统或子系统，会在某一时刻成为一个核心领域，或者至少是在一个新的核心中起到整合作用。这是不是意味着你应该提早预计到这种事情的发生，并提早建模，就像这个系统会最终采用DDD一样？我觉得这种方法并不明智。但我还是要说，你应该让你的团队尽可以开发出最好的软件，即使团队和领域专家没有常规的探讨。越是良好设计的系统，越容易演化维护，并在它需要担任一个比以往更重要的角色时及时扩展。 我觉得这里的重点是，了解何时及如何正确地采用DDD，同时不要把暂时不考虑使用DDD的那部分当作可以产出质量糟糕的软件的不毛之地，这是种不负责任的做法。 另一个建议是有序。即使一个没有用DDD建模的系统，也可以发布某些重要的领域事件，或提供一个开放主机服务作为它的服务级契约的一部分。请记住，即使是一个令人厌烦的遗留系统，也能够在改造后在最低程度上发布领域事件，这就不需要做出什么翻天覆地的大改动了。实现这点不需要对DDD进行很大的投入，只需和一两个团队共同整理出在系统中进行信息交换所需的领域事件或API就可以了。如果你的服务契约成为整个公司的重要部分，那就到了可以创建一个组织级公共语言（Published Language）的时候了，这是DDD策略设计中的另一个重要组件。 你可以看一看我书中的某个示例模型：认证及访问上下文是如何采用这一途径的。认证及访问上下文被看作一个通用的子领域，因此它并未完全采用DDD设计，但它依旧是设计良好的。它发布重要的领域事件，并提供了一个开放主机服务，以允许其它系统，如核心DDD领域与它进行集成。
| 
