DRY, KISS, and YAGNI

Beyond patterns and principles lie the "Common Sense" rules of architecture. These acronyms act as a filter during code reviews to ensure your system doesn't collapse under its own weight.

1. DRY: Don't Repeat Yourself

Every piece of knowledge or logic must have a single, unambiguous representation within a system. Duplicated code is a bug waiting to happen. However, beware of "Atheistic DRY"—where you DRY out code that just happens to look similar but represents different business concepts.

2. KISS: Keep It Simple, Stupid

The most elegant solution is the simplest one. Complexity is a cost that must be justified. If you can solve a problem with a simple switch expression, don't build a complex State Pattern with 10 classes.

3. YAGNI: You Ain't Gonna Need It

Software developers are addicted to speculating about the future. "What if the client wants to switch to Oracle next month?" So they spend 3 weeks building a generic database abstraction. YAGNI tells you: Only build what you need for the current requirement. Future-proofing is often just wasted effort and added maintenance.

4. Interview Mastery

Q: "When is it okay to violate DRY (Don't Repeat Yourself)?"

Architect Answer: "DRY should be violated when centralizing the logic would create a **Tight Coupling** between two unrelated business domains. For example, a 'User' in the Identity service and a 'User' in the Billing service might look exactly the same today, but they will evolve differently tomorrow. If you merge them into a single shared class just to satisfy DRY, you've created a dependency that will make it impossible to change Billing without breaking login logic. In this case, 'Clean Duplication' is better than a 'Dirty Abstraction'."