Every time I see a team celebrating their new "shared module," I remember this lesson. Reuse is a dangerous form of coupling. They found the same logic in two places and did what good engineers do: put it in one place and called it a win. Clean, responsible, textbook. Six months later, someone needs to change it. Suddenly, a small update for one team's requirements breaks three services, blocks two releases, and triggers an emergency meeting between people who've never talked to each other before. This is the cost nobody preaches about. DRY is one of those principles that feels unquestionably right until you apply it across team boundaries. The moment you share a module between domains, you're not just sharing code. You're creating a dependency that nobody owns and everyone resents. Before you reuse, ask: Will this change often? Does it belong to one domain? Are the consumers truly aligned in purpose? Will one team’s change surprise another team? If the answer to any of these is "I'm not sure," stop. Duplicate it. I know how that sounds. It feels lazy. It feels like the thing a junior developer does before they know better. But here's what nobody wants to say out loud: two independent implementations you control are almost always cheaper than one shared one serving masters with different goals. Duplication is a local problem. Coupling is an organizational problem. One of them you can fix in an afternoon. The other requires a meeting with five teams and someone's manager. Reuse isn't free. Treat it like the trade-off it is.