Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

The Good Architecture

The Good Architecture

Krzysztof Wawer

November 20, 2019
Tweet

More Decks by Krzysztof Wawer

Other Decks in Programming

Transcript

  1. KISS “Keep it simple, stupid” “Keep it stupid simple” U.S.

    Navy in 1960, aircraft engineer Kelly Johnson
  2. SOLID • SRP (Single Responsible Principle) • OCP (Open/Closed Principle)

    • LSP (Liskov Substitution Principle) • ISP (Interface Segregation Principle) • DIP (Dependency Inversion Principle) Robert C. Martin (Uncle Bob)
  3. SRP Single Responsible Principle • 2002 • A class should

    have one, and only one, reason to change http://rubyblog.pro/2017/05/solid-single-responsibility-principle-by-example
  4. OCP Open/Closed Principle • 1996 • You should be able

    to extend a classes behavior, without modifying it http://rubyblog.pro/2017/05/solid-open-closed-principle-by-example
  5. LSP Liskov Substitution Principle • 1987 • Barbara Liskov •

    Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T. http://rubyblog.pro/2017/06/solid-liskov-substitution-principle
  6. LSP Liskov Substitution Principle • objects in a program should

    be replaceable with instances of their subtypes without altering the correctness of that program http://rubyblog.pro/2017/06/solid-liskov-substitution-principle
  7. ISP Interface Segregation Principle • 1996 • Clients should not

    be forced to depend upon interfaces that they don't use. http://rubyblog.pro/2017/07/solid-interface-segregation-principle
  8. DIP Dependency Inversion Principle • 1996 • High-level modules should

    not depend on low-level modules. Both should depend on abstractions • Abstractions should not depend on details. Details should depend on abstractions. http://rubyblog.pro/2017/07/solid-dependency-inversion-principle
  9. YAGNI You aren't gonna need it • principle of extreme

    programming (XP) • XP co-founder Ron Jeffries has written: "Always implement things when you actually need them, never when you just foresee that you need them."
  10. Software Architecture Chronicles 2000s • 2003 - Domain Driven Design

    • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  11. Software Architecture Chronicles 2000s • 2003 - Domain Driven Design

    • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  12. Software Architecture Chronicles 2000s • 2003 - Domain Driven Design

    • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  13. CQS Command Query Separation • devised by Bertrand Meyer during

    his work on the Eiffel programming language • Queries: Return a result and do not change the observable state of the system (are free of side effects) • Commands: Change the state of a system but do not return a value
  14. Software Architecture Chronicles 2000s • 2002 - SRP (SOLID) •

    2003 - Domain Driven Design • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  15. Software Architecture Chronicles 2000s • 2002 - SRP (SOLID) •

    2003 - Domain Driven Design • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  16. Software Architecture Chronicles 2000s • 2002 - SRP (SOLID) •

    2003 - Domain Driven Design • 2005 - Ports & Adapters Architecture aka Hexagonal Architecture • ~2006 - CQRS & ES (Event Sourcing) • 2008 - Onion Architecture • 2012 - Clean Architecture
  17. @herbertograca • https://herbertograca.com • The Software Architecture Chronicles • The

    Containerization Chronicles • Domain Driven Design • Lean Architecture • Patterns of Enterprise Application Architecture • Patterns Principles and Practices of Domain-Driven Design • The mythical man-month