The Good Architecture

The Good Architecture

794f638b6f7f5132d5a13230e61c9db2?s=128

Krzysztof Wawer

November 20, 2019
Tweet

Transcript

  1. 11.

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

    Navy in 1960, aircraft engineer Kelly Johnson
  2. 12.
  3. 14.

    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)
  4. 15.

    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
  5. 17.
  6. 18.

    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
  7. 19.

    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
  8. 20.

    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
  9. 22.

    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
  10. 23.

    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
  11. 25.

    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."
  12. 27.

    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. 30.

    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
  14. 41.

    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
  15. 42.

    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
  16. 46.

    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. 50.

    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
  18. 52.

    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
  19. 55.

    @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
  20. 56.