What are software design principles?

A software design principle isn’t a rule you always have to follow. It’s a heuristic: a way of reasoning about complexity, duplication, and coupling that usually produces better results, depending on context.

KISS, DRY, SOLID, and the rest of the names in this topic aren’t laws. They’re criteria for making design decisions. Applying them mechanically, without thinking about the concrete problem, can produce a worse design than not applying them at all.

Why they’re worth knowing

• They give you shared vocabulary. Saying “this violates Single Responsibility” or “this is a DRY violation” communicates a design diagnosis to another developer who knows the principles, in a few words.
• They explain why a small change ends up taking so much work. When changing one business rule means touching ten files, or adding a new provider means rewriting a giant if, the symptom usually points at a specific principle. Naming it doesn’t solve the problem, but it narrows down where to look.
• They give you a test for how much to abstract. The question when designing isn’t “which pattern do I drop in here?” but “what concrete problem do I have, and which principle describes it best?”. The pattern, if you need one, comes after.

Principles aren’t absolute rules

Applying a principle where it isn’t needed can add indirection, layers, and abstractions that someone later has to understand and maintain. Applying SOLID to the letter in a small project can produce accidental complexity just as real as not applying it where it’s actually needed. Every principle in this topic comes with its flip side — what applying it badly looks like, or when it simply isn’t worth it — because that’s the part most often overlooked.

How this topic is organized

• General design principles — the six heuristics that come before anything else, whatever the paradigm: when something is unnecessarily complex, when duplicating is worse than abstracting (and the other way around), and how much one object needs to know about another.
• SOLID — the five principles specific to object-oriented design, with the test for not applying them where they add nothing.
• How to review a software design — the checklist of questions to use when designing or reviewing a component.

The examples in this topic are in Java. Several revolve around OrderService, Order, and PaymentProcessor, in an e-commerce domain that recurs across the entries.