DRY原则在DDD实践中应用 -Berthon

21-05-27 banq

开发人员喜欢使用首字母缩写词来说明“良好做法”(KISS,DRY,SOLID等)。通常,他们传达的想法非常容易掌握。

DRY是dont-repeat-yourself不要重复自己意思,其目的是更好地管理复杂性,但是通过以这种基本/教条的方式应用DRY,我们发现复杂性有所增加。

DRY原则被陈述为“每条知识片在系统中必须具有单一,明确,权威的表示形式”。

在这里,最重要的是“知识片”的概念,如果一段代码代表一条知识片,那么这段代码因为存在上下文,试图随着时间和用途不同保持其纯洁的单一、明确概念是不容易的:

  • 耦合:如果一个概念必须发展,那么也有必要对另一个链接的对象采取行动。
  • 另一方面,在这些概念之间造成有关所处上下文不同造成的理解歧义,这使得对代码的理解和维护更加复杂。

 

相同的代码,但业务用途不同

我们可以编写两段相同的代码,但它们在概念上并不代表相同的东西。为了识别它们,我们主要想找出调用这些代码片段的原因。

 

同一个名字,但不是同一个概念本身

一个人可以有几个同名但不属于同一上下文的概念:它们代表不同的东西。不同的业务流程、不同的信息是很好的信号,表明它们是不同的概念。为此,像事件风暴这样的研讨会也是识别它们的好工具,DDD的战略模式是将它们分开的好方法。

 

名称相同,用法不同

在相同的业务环境中,仍然可以用不同的方式表示相同的概念。一个典型的示例是一个简单的Web API,该API公开,保留信息并对其应用业务逻辑:我们可以拥有一个专门用于这三个角色的模型。这也是诸如分层架构甚至六边形架构之类的架构背后的主要动机:通过技术用途进行隔离。诸如CQRS之类的体系结构通过提供专用的写作模型和阅读模型而走得更远。然后,可以根据用例以几种方式表示相同的概念。

 

处理方式

如果在一段代码中,我发现了前面描述的症状;所以我的启发式办法是:我复制问题代码,然后删除条件以得出适合两个不同上下文情况的代码。

当我添加一个新的案例时,如果可以的话,我会避免立即做出决定,因为我可能缺乏对我的设计的知识和反馈。在这种情况下,我复制并调整现有的。如果以后我发现自己不得不在两个地方进行修改,那么可能有机会将代码相互合并。

1
猜你喜欢