本文要点
- 类似领域的两个独立项目，都使用 DDD 实现，这提供了一个有趣的机会，可以从失误中学习，从而做得更好。
- 有界上下文没有用在第一个项目中，因为那需要客户认同构建更小的系统。
- 这两个项目的最大不同是采用有界上下文以及创建一个反腐层。
- 通用语言仅限于有界上下文中。虽然有些术语可以在一个宽泛的领域内使用，但是定义会大相径庭。
在 Explore DDD 2017 大会上， Jimmy Bogard 谈到，他们获得了一个少有的机会，使他们可以在一个项目中进行他所谓的“返工（do-over）”。虽然不是完全从头开始重写，但他是参与了相关公司的两个非常类似的项目。InfoQ 采访了 Jimmy，了解他们如何运用从第一个项目中获得的经验教训使第二个项目取得更大的成功。
InfoQ：“如果我们可以把一切重新来做……”，这是那些从事大型软件项目开发的人常说的一句话。那种事后智慧通常可以为将来的项目提供指导。你们获得了一个少有的机会，可以在几年内实际从事两个客户和领域都几乎相同的项目。您能介绍下你们的客户、项目和主要目标吗？
Jimmy Bogard：最终用户是德州政府雇员，跨越许多不同的地理边界。第一个系统是面向青少年的案件管理系统，涉及法律程序的各个方面。这个青少年系统的整体目标不是惩罚，而是为违法的孩子提供帮助。客户包括州主要都市地区的县以及一个负责监督每个县的程序的州属机关。
第二个系统限制更多一些——为德州的县检察部门提供一个仅供他们使用的单一系统，而且仅用于成人程序。
InfoQ：当第一个项目在 2007 年启动时，DDD 还是一个相当新的理念。您的团队、客户对于 DDD 概念，如领域模型、通用语言、有界上下文，处于什么经验水平上？
Bogard：技术负责人（我自己）和架构师有几年构建 DDD 系统的经验。我的第一个 DDD 项目是在 2005 年，我还向那个项目的产品团队介绍了 XP 和 Scrum。对于有界上下文，我们就没有多少经验，虽然社区那会更关注结构化模式。
InfoQ：在这个过程中，您认为你们的经验水平导致了什么重大的失误吗？例如，所遵循的设计和开发实践导致了不必要的软件复杂度。
Bogard：不，没有。设计概念需要经过几个项目的迭代才会变成今天的样子。最大的错误——没有有界上下文——那会需要客户认同构建更小的系统。那没有发生。此外，我们非常谨慎，只构建我们需要的东西，并且根据我们知道的假设进行设计。由于范围太大，所以我们知道，如果没有完成比赛的希望，我们就不可能获得金牌，因此，我们尽力推迟复杂的需求。
InfoQ：该系统的构建和付款都是在一个机构完成的，但需要满足其他各种组织的需求。这导致领域模型设计做出了什么妥协吗？使用的语言真的是通用的吗？
Bogard：当然，这导致了设计上的妥协。有时候，我们的设计有点天真，一旦我们了解了一个方面的所有领域，我们就会看到，其设计与系统的其他部分基本上是不相容的。因此，我们就得妥协。在语言方面，我们发现，虽然术语是通用的，但背后的意思可能不同。只有把各个领域的专家都聚到一个屋里来，那才会显现出来。我们遇到过，每个人都认为他们同意了，但在会议结束时，没人同意。
InfoQ：在您的第二个项目中，方法上有哪些主要的差别，尤其是从 DDD 的角度来看？这些差别是如何反映在现实生活中的？
Bogard:：最大的差别是采用了有界上下文。我们在我们的系统和其他系统之间构建了一个反腐层，这样，当其他机构要和我们的系统连接时，就可以使用他们熟悉的术语和设计，但是我们内部会转换。例如，执法人员和检察人员都有“违法（offense）”的概念。在实际的系统里，我们会分成两个概念，因此，有两个名为“违法”的领域对象——一个面向执法人员，一个供我们自己使用。把它们分开，意味着我们可以单独修改其中一个而不影响另一个。
InfoQ：和严格遵循模式的第一个项目不同，您的第二个项目采用了更为务实的做法。对于完成项目满足客户需求并保证代码高质量、可维护，您有什么建议吗？
Bogard：那些项目是马拉松，而不是冲刺。要采用更偏向产品思维而不是项目思维的方法，设计要长远考虑，但要围绕我们已经做了验证的假设。如果我们有了新的发现，那么我们要制定计划把那些变化包含进来，而不是让我们的设计随着时间推移慢慢坏掉。
InfoQ：有些读者希望更多地了解您遵循的设计建议，您有什么要推荐的吗？
Bogard： SOLID 架构：分片而不是分层。
关于受访者
Jimmy Bogard 是 Headspring 的首席架构师，《MVC 实战》一书的作者。同时，他还是一名国际演讲者和多产的 OSS 开发人员。他是分布式系统、REST、消息传递、领域驱动设计、CQRS 方面的专家。
查看英文原文： The DDD Do-Over
评论