"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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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."):
Customerto get work done inside the Sales contextCustomerto get work done inside the Support contextCustomernecessary for the the Support context and Sales context to communicate/collaborate.Superficially there is repetition across the three
Customersbut they serve very different roles and more importantly neither context should let implementation details about the their internal handling of aCustomerleak out.