DEV Community

Discussion on: DRY & the Wrong Abstraction

Collapse
peerreynders profile image
peerreynders • Edited on

The issue is that there always is more nuance than the slogan suggests.

Point: Don't Repeat Yourself

"every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Just because there are two similar representations doesn't necessarily mean they refer to the same piece of knowledge. It's likely but in some cases the resemblance simply reflects the current incomplete understanding of the problem and its solution.

Counterpoint: Beware the Share (see also Fate-sharing).

Implementations sharing a common dependency are inherently coupled. If the implementations have slightly different requirements the common dependency absorbs complexity to accommodate that variation in order to be more "generic". When the requirements of one of the implementations change, the commonality has to adapt-often taking on complexity that doesn't benefit the other implementations, sometimes leading to a breaking change for the other implementations. So at times maintaining multiple distinct but much simpler dependencies can make maintenance simpler (Used Three Times).

Look at Bounded Context ("Beware the share. Check your context."):

  • The Customer to get work done inside the Sales context
  • The Customer to get work done inside the Support context
  • The Customer necessary for the the Support context and Sales context to communicate/collaborate.

Superficially there is repetition across the three Customers but they serve very different roles and more importantly neither context should let implementation details about the their internal handling of a Customer leak out.