“Don’t Repeat Yourself” or DRY is a popular principle among programmers to produce better-looking code.

But the principle, applied well, is actually not about the code:

“Don’t Repeat Yourself” was never about code. It’s about knowledge.¹

It’s opposing the trend to copy & paste the same stuff over and over again which makes maintenance harder since you have to track down all occurrences of code with similar meaning. Because of this, the distinction of problem space and solution space is useful: if the repeated part is a Thing in the problem space, model it as a single module.

DRY relates to the Domain, not to code – if you apply DRY to code only, you end up with weird modularization in the solution space that doesn’t match the problem space’s partitioning anymore.

The business rule in my example is not “Max 3 products allowed”.
There are in fact two business rules: “A basket is not allowed to
have more than three products” and “A shipment is not allowed to
have more than three products”. Two rules, no matter how similar,
should have two individual representations in the
model.¹

DRY can produce merely coincidental cohesion

Happens when one applies DRY to produce false generalizations, just to de-duplicate similar-looking code.

This can be dangerous when the code actually has different meaning or intent.

Yourdon stresses that coincidental cohesion is not bad.² It can nevertheless result in a code base which is easier to maintain than before reducing duplications, for example.