开发人员喜欢使用首字母缩写词来说明“良好做法”（KISS，DRY，SOLID等）。通常，他们传达的想法非常容易掌握。
DRY是dont-repeat-yourself不要重复自己意思，其目的是更好地管理复杂性，但是通过以这种基本/教条的方式应用DRY，我们发现复杂性有所增加。
DRY原则被陈述为“每条知识片在系统中必须具有单一，明确，权威的表示形式”。
在这里，最重要的是“知识片”的概念，如果一段代码代表一条知识片，那么这段代码因为存在上下文，试图随着时间和用途不同保持其纯洁的单一、明确概念是不容易的：
- 耦合：如果一个概念必须发展，那么也有必要对另一个链接的对象采取行动。
- 另一方面，在这些概念之间造成有关所处上下文不同造成的理解歧义，这使得对代码的理解和维护更加复杂。
相同的代码，但业务用途不同
我们可以编写两段相同的代码，但它们在概念上并不代表相同的东西。为了识别它们，我们主要想找出调用这些代码片段的原因。
同一个名字，但不是同一个概念本身
一个人可以有几个同名但不属于同一上下文的概念：它们代表不同的东西。不同的业务流程、不同的信息是很好的信号，表明它们是不同的概念。为此，像事件风暴这样的研讨会也是识别它们的好工具，DDD的战略模式是将它们分开的好方法。
名称相同，用法不同
在相同的业务环境中，仍然可以用不同的方式表示相同的概念。一个典型的示例是一个简单的Web API，该API公开，保留信息并对其应用业务逻辑：我们可以拥有一个专门用于这三个角色的模型。这也是诸如分层架构甚至六边形架构之类的架构背后的主要动机：通过技术用途进行隔离。诸如CQRS之类的体系结构通过提供专用的写作模型和阅读模型而走得更远。然后，可以根据用例以几种方式表示相同的概念。
处理方式
如果在一段代码中，我发现了前面描述的症状；所以我的启发式办法是：我复制问题代码，然后删除条件以得出适合两个不同上下文情况的代码。
当我添加一个新的案例时，如果可以的话，我会避免立即做出决定，因为我可能缺乏对我的设计的知识和反馈。在这种情况下，我复制并调整现有的。如果以后我发现自己不得不在两个地方进行修改，那么可能有机会将代码相互合并。