Summarized Key Software Design Principles
Here's a summarized table of the key software design principles across all categories, formatted as:
Principle Name |
Purpose |
|
| 1 | Separation of Concerns (SoC) | Organize code around distinct responsibilities. |
| 2 | Single Responsibility Principle (SRP) | Each module/class should have one reason to change |
| 3 | High Cohesion / Low Coupling | Create modular, easy-to-maintain systems |
| 4 | Dependency Inversion Principle (DIP) | Depends on abstractions, not concrete implementations |
| 5 | Don't Repeat Yourself (DRY) | Avoid code duplication |
| 6 | KISS (Keep It Simple, Stupid) | Favor simplicity and clarity |
| 7 | YAGNI | Don't build what you don't yet need |
| 8 | Law of Demeter | Minimize knowledge of external modules |
| 9 | Stable Abstractions Principle | Abstract modules should be less likely to change |
| 10 | Stable Dependencies Principle | Depend on less volatile modules |
| 11 | REP / CCP / CRP | Ensure cohesive and replaceable components |
| 12 | Open/Closed Principle (OCP) | Open for extension, closed for modification |
| 13 | Liskov Substitution Principle (LSP) | Subtypes must be substitutable for base types |
| 14 | Interface Segregation Principle (ISP) | Prefer many small, specific interfaces |
| 15 | Immutability | Prefer unchanging data for safety and predictability |
| 16 | Pure Functions | Functions without side effects |
| 17 | Composition over Inheritance | Prefer combining simple behaviors over class hierarchies |
| 18 | Referential Transparency | Same input always yields the same output |
| 19 | Shared-nothing Architecture | Avoid shared state in concurrent systems |
| 20 | Actor Model / Message Passing | Safe and isolated concurrency |
| 21 | Idempotency | Safe retries in distributed systems |
| 22 | Reentrancy | The function can safely be re-entered |
| 23 | Principle of Least Privilege | Minimize permissions to reduce the attack surface |
| 24 | Fail Securely | Default to secure behavior |
| 25 | Secure by Design | Build in security from the start |
| 26 | Defense in Depth | Layered security mechanisms |
| 27 | Validate Input / Sanitize Output | Prevent injections and XSS |
| 28 | Testability | Code should be easy to test |
| 29 | AAA (Arrange-Act-Assert) | Structure tests clearly |
| 30 | Isolation Independent | focused unit tests |
| 31 | Given-When-Then Behavior-Driven | Development structure |
| 32 | Inversion of Control (IoC) | Decouple code from its dependencies |
| 33 | Ubiquitous Language | Shared terminology between devs and domain experts |
| 34 | Bounded Context | Clear domain boundaries |
| 35 | Domain Events | Decoupled and reactive business logic |
| 36 | Anti-Corruption Layer | Shield domain from external changes |
| 37 | Readability Over Cleverness | Clear code trumps smart but cryptic code |
| 38 | Refactor Often | Continuously improve design |
| 39 | Boy Scout Rule | Leave the codebase better than you found it |
| 40 | Meaningful Naming | Use names that reveal intent |
| 41 | Graceful Degradation | System continues in limited mode on failure |
| 42 | Backpressure | Control incoming load |
| 43 | Circuit Breakers / Timeouts | Prevent cascading failures |
| 44 | Retries with Exponential Backoff | Robust retry strategy |
| 45 | Bulkheads | Isolate components to contain failure |
| 46 | RESTful Design | Predictable and standard APIs |
| 47 | HATEOAS | Guide clients through API with hyperlinks |
| 48 | Statelessness | Improve scalability |
| 49 | Rate Limiting | Prevent abuse |
| 50 | Versioning | Smooth API evolution |
| 51 | Unidirectional Data Flow | Predictable state transitions |
| 52 | MVC / MVVM | Separate presentation from logic |
| 53 | Responsive Design | Ensure mobile and desktop usability |
| 54 | Progressive Enhancement | Enhance progressively for capable clients |
| 55 | Accessibility (a11y) | Inclusive experience for all users |
| 56 | Everything as Code Automate | Infrastructure and configuration |
| 57 | Immutable Infrastructure | Prevent configuration drift |
| 58 | Shift Left Testing | Early in the process, begin testing |
| 59 | Observability | Measure logs, metrics, and traces |
| 60 | Continuous Feedback | Fast loops for improvement |
| 61 | Normalization / Denormalization | Balance performance vs. consistency in DB |
| 62 | ACID | Strong transactional guarantees |
| 63 | BASE | Scalability through eventual consistency |
| 64 | Schema Evolution | Support DB changes over time |
| 65 | Indexing | Optimize read queries |
| 66 | Feedback Loops | Keep users informed |
| 67 | Perceived Performance | Make the system feel fast |
| 68 | Consistency | Predictable interface and experience |
| 69 | Error Prevention & Recovery | Help users avoid and recover from errors |
| 70 | Single Responsibility per Service | Each microservice does one thing well |
| 71 | Service Contracts | Clear API expectations |
| 72 | Event-Driven Architecture (EDA) | Loose coupling via events |
| 73 | Service Discovery | Auto-locate services in dynamic environments |
| 74 | Data Ownership | Per Service Avoid shared databases |
| 75 | Information Hiding | Hide internal implementation details |
| 76 | Least Common Mechanism | Reduce unnecessary shared resources |
| 77 | Minimize Mutability | Safer and easier to reason about |
| 78 | BDUF is Risky | Avoid heavy upfront designs |
| 79 | Emergent Design | Design evolves through refactoring |
| 80 | Cognitive Load Awareness | Reduce mental overhead for developers |
| 81 | Naming is a Design | Activity Express system intent through naming |
| 82 | EAFP vs. LBYL | Idiomatic error handling |
| 83 | RAII | Predictable resource lifecycle |
| 84 | Decorator Pattern | Without changing the code, you modify the behavior |
| 85 | Strategy Pattern | Swap algorithms dynamically |
| 86 | Factory Pattern | Encapsulate object creation |
| 87 | Observer Pattern | Subscribe to state changes |
| 88 | Circuit Breaker Pattern | Isolate failures in distributed systems |
| 89 | Self-Documenting Code | Clear, intention-revealing code |
| 90 | Living Documentation | Keep docs in sync with the codebase |
What is your next step?
Pick one principle from this list and apply it to a recent or current project.
Happy coding!