Apply SOLID, DRY, YAGNI, and KISS consistently at service, module, and system boundaries to ensure long-term maintainability, testability, and evolvability.
1. SOLID Principles (The Foundation of Service Design)
SOLID guides how services and modules interact and evolve.
A. S: Single Responsibility Principle (SRP)
- Principle: A class or service should have only one reason to change.
- System-Level: Microservices embody SRP — each focused on a single business capability.
B. O: Open/Closed Principle (OCP)
- Principle: Open for extension, closed for modification.
- System-Level: Clear extension points (policies/strategies) to add features without touching core code.
C. L: Liskov Substitution Principle (LSP)
- Principle: Subtypes must be substitutable for base types.
- System-Level: Stable API contracts; internal changes must not break consumers.
D. I: Interface Segregation Principle (ISP)
- Principle: Clients shouldn’t depend on interfaces they don’t use.
- System-Level: Fine-grained APIs and event schemas; avoid “fat” endpoints and events.
E. D: Dependency Inversion Principle (DIP)
- Principle: Depend on abstractions, not concretes.
- System-Level: Depend on interfaces/contracts (broker/repository), not vendor SDKs.
2. General Principles for Architectural Design
A. DRY: Don’t Repeat Yourself
- Principle: Single, authoritative representation of knowledge.
- System-Level: Avoid duplicating business logic across services; centralize pricing, etc.
B. YAGNI: You Aren’t Gonna Need It
- Principle: Implement only what’s needed now.
- System-Level: Start simple (Modular Monolith); add distributed complexity only when required.
C. KISS: Keep It Simple, Stupid
- Principle: Favor simplicity over complexity.
- System-Level: Prefer managed services for operational simplicity and stability.
Principles Emphasis by Architecture Style
Relative emphasis (1–5) of principles across Monolith, Modular Monolith, Microservices, Serverless.