Software design principles for evolving architectures
Download as PPTX, PDF24 likes12,027 views
The document outlines key software design principles and architectural patterns for developing flexible and maintainable systems. It emphasizes concepts such as DRY, YAGNI, KISS, and the SOLID principles, highlighting the importance of cohesion and low coupling in design. It also discusses architecture decisions, including the benefits of microservices and layered approaches to enhance agility, scalability, and testability.
Software design principles for evolving architectures
- 2. Principles
- 3. DRY – Don’t repeat yourself. Every knowledge in a system must have a single authoritative, unambiguous representation. – Pragmatic Programmers
- 4. YAGNI – You aren’t gonna need it. Embrace principle of last responsible moment Postpone decisions until you can’t postpone them any further. Courage is postponing the decisions tomorrow to tomorrow. – Kent Beck.
- 5. KISS- Keep it simple and stupid Simple keeps focus Inherent & Accidental Complexity Good software design hides inherent complexity and avoids accidental complexity.
- 6. Principle of Cohesion High cohesion & Low Coupling Removing and reducing coupling creates better design.
- 7. Avoid long methods • Hard to test • Hard to reason • Hard to debug • Hard to change • Increases coupling, decreases cohesion SLAP – Single level of abstraction principle and compose method pattern to the rescue.
- 8. Principle of least knowledge (Law of Demeter) Consumer of a method or a class shouldn’t know the inner implementation details.
- 9. SOLID Principles Single Responsibility Principles: A class or method should have only one reason to change. Open-Closed Principle: A class should be open for extension but closed for modification. Liskov Substitution Principle: Classes that implements the same interface or base class can be substituted. Interface Segregation Principle: Interfaces should be specialized but not too special. Dependency inversion (Inversion of control): Depend on abstractions not implementations.
- 10. Architecture
- 12. Architecture is set of design decisions that are hard to change. Shared understanding of a system between the people who are leading the project. “Describe me with 4 objects how system works” – Kent Beck.
- 13. Avoid big up front design
- 14. Time Understanding Features based on Value and Architectural impacts
- 15. Reversibility Last Responsible Moment YAGNI Minimize Framework and Libraries
- 16. Users/ External Quality Software/ Internal Quality
- 17. Design Stamina
- 19. Presentation Layer Business Layer Service Layer Persistence Layer Closed Closed Open Layered Architecture
- 20. Monolith
- 21. Feature based Slicing F1 F2 F3 F4 .. FN Cross cutting concerns
- 23. Event Driven Architecture Event Processors ESB, Queue, Hub Mediator Topology
- 24. Event Driven Architecture Event processors. Broker Topology
- 26. Layered Event Driven Microkernel MicroService Agility Deployment Testability Performance Scalability Development Comparison