Architecture Principles: SOLID and DRY

"Good code is like a set of Legos. Great code is like a set of Legos where the pieces don't exist yet."

Why do some projects become "Legacy Spaghetti" in $6$ months while others (like the Linux Kernel) last for $30$ years? The answer is not "Better programmers." The answer is Principles.

SOLID and DRY are the grammatical rules of software. They prevent your app from becoming a "House of Cards" where pulling one thread causes the whole building to collapse. This 1,500+ word guide explores the "Structural Integrity" of high-end software.

1. DRY: Don't Repeat Yourself (The "Single Source of Truth")

The most misunderstood principle. DRY does NOT mean "Never copy-paste code."

The Definition: Every piece of Knowledge must have a single, unambiguous representation within a system.
If you have three different tables that store a "Username" format, you have broken DRY.
If you change the format to allow "Emojis," you have to remember to fix it in 3 places. You will forget one. You will have a bug.

2. SOLID: S is for Single Responsibility

A class or module should have ONE reason to change.

The Violation: A UserManager class that handles Database saves, Email sending, and Password hashing.
The Problem: If you want to change your Email provider from AWS to SendGrid, you shouldn't have to touch the "Database" code.

3. SOLID: O is for Open/Closed

Software should be Open for extension but Closed for modification.

How do you add a "Discount Code" logic to your checkout without changing the Checkout.java file?
The Solution: Use a Strategy Pattern. You pass a list of "Rules" to the checkout. To add a new holiday discount, you just write a new "Rule" file. You never touch the core checkout code.

4. SOLID: D is for Dependency Inversion

This is the king of architecture. Your High-Level logic should not depend on Low-Level details.

The Wrong Way: UserService calls PostgresDatabase directly.
The Right Way: UserService calls an IDatabase Interface.
The Benefit: You can swap Postgres for a Mock database during testing in $1$ second. This is what makes software Testable.

5. The "Over-Engineering" Warning

Principles are not "Laws."

If you follow DRY too strictly, you might "Couple" unrelated code.
Sometimes, two pieces of code look the same but they change for different reasons. This is called "Accidental Duplication."
The Professional Rule: Duplicate code is cheaper than the wrong abstraction. Only apply SOLID when you feel the "Pain" of maintenance.

Summary: The Principles Checklist

Single Truth: Ensure business rules (like "What is a valid email?") only live in one file.
Decouple: Use interfaces to protect your logic from your database.
Liskov Check: Ensure your sub-classes don't break the rules of their parents.
Small Interfaces: Don't force a user to implement save() if they only need to read().
Avoid God-Classes: If a file is >500 lines, it probably has too many responsibilities.

Principles are the "Language" of the architect. By mastering the modularity of SOLID and the consistency of DRY, you gain the ability to build systems that grow indefinitely without becoming a "Legacy" mess. You graduate from "Typing code" to "Architecting Longevity."

Part of the Architecture Masterclass — engineering the longevity.