Clean Architecture

Short introduction about Clean Architecture

Transcript

1. Clean Architecture Thibaut Coutard iOS developer
2. What is it ?
3. Uncle Bob • co-autor of the agile manifest • Author of Clean Code • His blog cleancoder.com
4. Why ? • Easier to change • Easier to maintain • Less bugs • Less developers needed
5. S.O.L.I.D
6. S.O.L.I.D • Single Responsibility Principle
7. S.O.L.I.D • Single Responsibility Principle • Open Close Principle
8. S.O.L.I.D • Single Responsibility Principle • Open Close Principle • Liskov Substitution Principle
9. S.O.L.I.D • Single Responsibility Principle • Open Close Principle • Liskov Substitution Principle • Interface Segregation Principle
10. S.O.L.I.D • Single Responsibility Principle • Open Close Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle
11. S.O.L.I.D
12. S.ingle Responsibility Principle
13. S.ingle Responsibility Principle • One reason to change • Do one thing • Responsible to one actor
14. O.pen Close Principle
15. O.pen Close Principle • Open for extension - Close for modi fi cation • Protects higher-level components from changes in lower-level components
16. View Presenter Interactor Repository
17. L.iskov Substition Principle
18. L.iskov Substition Principle • Class substituted by another without breaking the caller
19. Repository DBInterface Realm Gateway CoreData Gateway <I>
20. I.nterface Segregation Principle
21. I.nterface Segregation Principle • Harmful to depend on modules that contains more than you need • Give only the essentials
22. UserAPI ———— +getAll +get +post UserList AddUser GetAllUserAPI ———— +getAll <I> GetUserAPI ———— +get <I> PostUserAPI ———— +post <I> UserPro fi le
23. D.ependency Inversion Principle
24. D.ependency Inversion Principle • Flexible using abstraction • Interfaces less volatiles • Never mention the name of anything concrete or volatile
25. D.ependency Inversion Principle Interactor Interactor Output Presenter
26. Clean Architecture
27. -M. Conway « organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. »
28. Clean Architecture • A good architecture allow changes • Be careful of duplication that is not real • Premature decisions are ones that have nothing to do with business requirements • Draw Boundaries between business and GUI, GUI and DB, DB and business
36. Don’t depend on volatile things !
37. Going deeper • https://github.com/coutar-t/GW2Achievements • Clean Architecture, Robert C. Martin • V.I.P.E.R • Clean Swift • https://speakerdeck.com/coutart/clean-architecture