DDD游击队 - yannick grenzinger

2018年6月26日，我很幸运地被DDD巴黎团队邀请与一些DDD明星同台演讲，如 Mathias Verraes ， Yves Reynhout 和 Eric Evans ，他是设计驱动设计书籍的作者。这次所有的会议都很棒。

最后的讨论小组对DDD和我们作为开发人员的工作充满洞察力。我强烈建议花些时间去看他们（ 这里的视频 ），这只有20分钟，像我这样的法语演示用英文字幕！

在我的演讲中，我谈到了“Guerrilla DDD”。这个术语来自我团队的Scrum回顾展中的讨论，并受到UX领域的启发，设计师面临着无法正常工作的困难，开始谈论游击队或“如何破解组织工作” “（ 见本书 ）。

为什么使用领域驱动设计？

这个词是 埃里克埃文斯 在他的同名书中创造的。

使用维基百科的优秀定义是：

• 将项目的主要重点放在核心领 域 和域逻辑上
• 基于领域模型的复杂设计
• 启动技术 专家 和 领域专家 之间的创造性协作，以迭代方式完善解决特定领域问题的概念模型。

DDD的最大优点之一是它促使开发人员（以及整个IT团队）持续改进他们的工作方式。

通过将自己融入思维模式，他们将花时间真正了解他们正在研究的领域（即业务）。他们将在代码中明确且清晰地预测（作为建模）业务领域，使其几乎可被业务人员阅读。

事实上，是的，对于那些还没有这种心态的开发人员来说，这是DDD的最大优势。在您发现许多软件开发环境的严酷现实之前：

我们称之为业务人员，即业务分析师或产品所有者，并不真正掌握他们被分配到的领域相关知识。

在遗留软件环境中非常明显。很多时候，他们真的不知道如何在这些凌乱的代码中实现业务规则。当他们发生可怕的“我们将查看文档”时，你知道你将有一个漫长而艰难的旅程。当然，我们谈论的是“遗留”应用程序，因此没有BDD或DDD实践来帮助我们重新创建业务知识。

在其他情况下，他们真正掌握的是业务在遗留旧应用程序中的预测。他们就是Alberto Brandolini所说的 Dungeon Master ，“他的专业知识是从现有系统的复杂性中建立起来的”。

这种情况的最大问题是遗留的、旧的预测很少代表真正的业务领域。

在某些时候，业务领域将自己与一个糟糕的应用程序对齐，我称之为功能性债务，这比 技术债务 更糟糕。

此外，这并不是因为这些人不够聪明，而是因为有许多心理偏见推动这个方向，如“ 达克效应 （无知的人总是自以为聪明） ”或大多数“ WYSIATI 所见即所有”。

收回控制权

我将给出一个真实的例子来更好地理解问题是什么，如何重新获得控制并将真正的业务领域放回产品和代码中。

我们的团队正在重新设计国际投资银行的旧应用程序。该领域主要是复杂融资请求的审批流程。审批流程需要支持不同用户的分析和决策。

第一个重要功能是创建一个任务管理系统（想想待办事项列表），以帮助他们查看要处理或跟进的请求。此任务管理主要是为了表明团队可以快速为旧应用程序周围的用户带来价值。我们必须检索旧遗留数据库中的请求和决定，这是真正的主要来源。

为此，有两种情况：用户要么是主动加入团队，要么被团队邀请。对于后者，我们发现了令人不安的事情：一些用户被要求分配到多个团队......最多10个......使得任务管理系统对这些用户几乎无用。

在这一点上，大多数开发人员将接受这个事实并实现这一需求，而不是眨眼:(

当然，业务要求我们这样做！他们还将继续添加变通方法和怪癖，以使整个事情可用，但同时，迅速增加代码库的 意外复杂性 。

在这一点上，DDD经历了真理的考验。为了兑现DDD的承诺，你必须说“不”并推动组织改变。

首先，尽一切可能看到真正的用户。

在我们的案例中，花一个小时与应用程序的用户进行讨论是一次神奇的体验，因为他解释了为什么许多用户被分配到多个团队。

在他们的日常活动中，每个团队都是一组用户，每个团队主要代表一个部门。在遗留应用程序的生命周期开始时，创建了新的一组团队，每个新团队都与原来特定部门相关联。

然而，修改团队是如此困难，以至于每次用户需要关注新的法律实体或者公司在团队之间重新分配时（因为内部重组），选择将用户添加到另一个团队。也许代码库已经不够灵活，或者企业不想投资这种能力。

最后应该是简单的，如下图所示:

实际上是这样：

我们发现的是以前提出的功能性债务的概念。

在开发团队中，我们强烈反对这一点，业务代表正在努力保留遗留应用程序中实现的内容，主要是因为他们已经习惯了它并且他们害怕创造新的东西。

我们不得不多次解释功能性债务使项目处于危险之中，意外的复杂性，潜在的错误和可用性问题。​​​​​​​

幸运的是，开发团队足够强大，能够让每个人都了解在应用程序中设计团队的必要性，以及业务团队日常工作的方式。

最后，我们创建的设计现在接近于此：简单且更好地将业务投影到代码中。

游击队开发团队最终获胜，并有其快乐的结局故事。

结论

在某些情况下，要真正做DDD，您将不得不在遗留应用程序中分解原来组织结构，错误的组织结构对业务的错误投射影响，您将不得不进入游击队方式去改变它们。