Tweet
Tweet

Slide 1

Slide 1 text

Clean Architecture Iván Álvarez Frías Erik Jhordan González Reyes [email protected] @Ivanhoe github.com/ivanhoe [email protected] @ErikJhordan_Rey github.com/erikcaffrey

Slide 2

Slide 2 text

“Clean code always looks like it was written by someone who cares”

Slide 3

Slide 3 text

IOS Smells

Slide 4

Slide 4 text

/ SCHIBSTED MEDIA GROUP ● God View Controller ● Similar code everywhere ● Coupled Code ● My Code is not testable ● Hacks everywhere ● Architecture based on Inheritance ● A lot External Dependencies IOS Smells

Slide 5

Slide 5 text

STUPID

Slide 6

Slide 6 text

/ SCHIBSTED MEDIA GROUP STUPID Singleton Invasion Tight Coupling Untestability Premature Optimization Indescriptive Naming Duplication

Slide 7

Slide 7 text

/ SCHIBSTED MEDIA GROUP From STUPID to SOLID code These are principles, not laws!

Slide 8

Slide 8 text

/ SCHIBSTED MEDIA GROUP

Slide 9

Slide 9 text

SOLID

Slide 10

Slide 10 text

/ SCHIBSTED MEDIA GROUP SOLID Single Responsibility Principle Open / Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

Slide 11

Slide 11 text

“Depend upon abstractions. Do not depend upon concrete classes”

Slide 12

Slide 12 text

Architecture

Slide 13

Slide 13 text

/ SCHIBSTED MEDIA GROUP Architecture #By Martin Fowler “Architecture as a word we use when we want to talk about design but want to puff it up to make it sound important.”

Slide 14

Slide 14 text

Clean Architecture

Slide 15

Slide 15 text

/ SCHIBSTED MEDIA GROUP Entities Use Cases Controllers Gateways Presenters Devices W eb UI DB External Interfaces Frameworks and drivers Interface Adapters Business Rules Domain Logic

Slide 16

Slide 16 text

Dependency Rule

Slide 17

Slide 17 text

/ SCHIBSTED MEDIA GROUP Source code dependencies can only point inwards! Nothing in an inner circle can know anything at all about something in an outer circle. In particular, the name of something declared in an outer circle must not be mentioned by the code in the an inner circle. That includes, functions, classes. variables, or any other named software entity. Dependency Rule

Slide 18

Slide 18 text

Entities

Slide 19

Slide 19 text

/ SCHIBSTED MEDIA GROUP Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise. Entities

Slide 20

Slide 20 text

Use Cases

Slide 21

Slide 21 text

/ SCHIBSTED MEDIA GROUP The software in this layer contains application specific business rules. It encapsulates and implements all of the use cases of the system. These use cases orchestrate the flow of data to and from the entities, and direct those entities to use their enterprise wide business rules to achieve the goals of the use case. Use Cases

Slide 22

Slide 22 text

Interface Adapters

Slide 23

Slide 23 text

/ SCHIBSTED MEDIA GROUP The software in this layer is a set of adapters that convert data from the format most convenient for the use cases and entities, to the format most convenient for some external agency such as the Database or the Web. Interface Adapters

Slide 24

Slide 24 text

Frameworks and Drivers

Slide 25

Slide 25 text

/ SCHIBSTED MEDIA GROUP The outermost layer is generally composed of frameworks and tools such as the Database, the Web Framework, etc. Generally you don’t write much code in this layer other than glue code that communicates to the next circle inwards. This layer is where all the details go. The Web is a detail. The database is a detail. We keep these things on the outside where they can do little harm. Frameworks and Drivers

Slide 26

Slide 26 text

IOS Clean architecture

Slide 27

Slide 27 text

/ SCHIBSTED MEDIA GROUP VIPER

Slide 28

Slide 28 text

/ SCHIBSTED MEDIA GROUP View Presenter ViewController Use Case Use Case Use Case Domain Model Data Source Implementation Repository Repository Data Source Data Source Data Source Implementation Presentation Layer Domain Layer Data Layer

Slide 29

Slide 29 text

Presentation Layer

Slide 30

Slide 30 text

/ SCHIBSTED MEDIA GROUP

Slide 31

Slide 31 text

/ SCHIBSTED MEDIA GROUP ● MVC ● MVP ● MVVM UI Design Patterns

Slide 32

Slide 32 text

Talk Schedule Model View Controller Model What to display? View How it’s displayed? Controller Formatting the model for display and handling events like user input.

Slide 33

Slide 33 text

Talk Schedule Model View Presenter The MVP pattern allows separate the presentation layer from the logic, so that everything about how the interface works is separated from how we represent it on screen. Ideally the MVP pattern would achieve that same logic might have completely different and interchangeable views.

Slide 34

Slide 34 text

Model View Presenter View Presenter Model User interaction notify user event request data Update UI with entities delivers entities

Slide 35

Slide 35 text

/ SCHIBSTED MEDIA GROUP https://github.com/erikcaffrey/Swift-ModelViewPresenter

Slide 36

Slide 36 text

Talk Schedule Model View ViewModel Is an architectural approach used to abstract the state and behaviour of a view, which allows us to separate the development of the UI from the business logic.

Slide 37

Slide 37 text

Model View ViewModel View ViewModel Model DataBinding and Commands ViewModel updates the model Send Notifications Send Notifications

Slide 38

Slide 38 text

/ SCHIBSTED MEDIA GROUP What Do They have in common?

Slide 39

Slide 39 text

Allows separate the view from the business logic and data logic.

Slide 40

Slide 40 text

/ SCHIBSTED MEDIA GROUP What pattern Should I use?

Slide 41

Slide 41 text

/ SCHIBSTED MEDIA GROUP ● These patterns try to solve the same problems ● Both patterns are going to improve code quality and testability. ● Think about these patterns and use the one you understand better. UI Patterns

Slide 42

Slide 42 text

Domain Layer

Slide 43

Slide 43 text

/ SCHIBSTED MEDIA GROUP ● Contains Business Logic ● No Code specific to a framework ● Use Command Pattern (optional) Domain

Slide 44

Slide 44 text

/ SCHIBSTED MEDIA GROUP Command Pattern Holding all your business logic, its main component is UseCase that gives you an easy way to define your application use cases and execute them in a background thread.

Slide 45

Slide 45 text

Data Layer

Slide 46

Slide 46 text

/ SCHIBSTED MEDIA GROUP Use a repository to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model. The business logic should be agnostic to the type of data that comprises the data source layer. For example, the data source layer can be a database, a SharePoint list, or a Web service. Repository Pattern

Slide 47

Slide 47 text

/ SCHIBSTED MEDIA GROUP Data Mapper Repository Client Business Logic Business Entity Business Entity Persist Query Query Object Data Source

Slide 48

Slide 48 text

/ SCHIBSTED MEDIA GROUP Software Design Pattern used to facilitate the usage of Dependency Inversion. It consists of passing dependencies (inject them) via constructor or setter in order to extract the task of creating modules out from other modules. Objects are instantiated somewhere else and passed as constructor attributes when creating the current object. Dependency Injection

Slide 49

Slide 49 text

/ SCHIBSTED MEDIA GROUP ● Since dependencies can be injected and configured externally we can reuse those components. ● We can just change the implementation of any object without having to make a lot of changes in our codebase, since that object instantiation resides in one place isolated and decoupled. ● Dependencies can be injected into a component: it is possible to inject mock implementations of these dependencies which makes testing easier. Dependency Injection Advantages

Slide 50

Slide 50 text

/ SCHIBSTED MEDIA GROUP ● But here it comes a new problem. If we can’t create modules inside modules, there must be a place where those modules are instantiated. ● Modules with huge constructors including lots of dependencies, code will become dirty and hard to read. Dependency Injection Smells

Slide 51

Slide 51 text

Solution ….

Slide 52

Slide 52 text

Dependency Injector

Slide 53

Slide 53 text

/ SCHIBSTED MEDIA GROUP We can consider it as another module in our app that is in charge of providing instances of the rest of modules and inject their dependencies. Dependency Injector ● Service Locator ● Swinject ● Typhoon

Slide 54

Slide 54 text

/ SCHIBSTED MEDIA GROUP Clean Architecture Principles ● The Dependency Rule ● Presentation is decoupled from domain ● Domain module can be a layer module. ● Data layer decouples the rest of the app ● Independent of Frameworks. ● Independent of UI ● Independent of Database ● Entities Representing Enterprise Rules

Slide 55

Slide 55 text

/ SCHIBSTED MEDIA GROUP Conforming to these simple rules is not hard, and will save you a lot of headaches going forward. By separating the software into layers, and conforming to The Dependency Rule, you will create a system that is intrinsically testable, with all the benefits that implies. When any of the external parts of the system become obsolete, like the database, or the web framework, you can replace those obsolete elements with a minimum of fuss. Clean Architecture Conclusion #Uncle Bob

Slide 56

Slide 56 text

Routing

Slide 57

Slide 57 text

/ SCHIBSTED MEDIA GROUP Routing ● Segues ● TabBarViewController ● NavigationViewController ● Push ● Search Solution ● Navigator ● Wireframe

Slide 58

Slide 58 text

Show me code!

Slide 59

Slide 59 text

/ SCHIBSTED MEDIA GROUP

Slide 60

Slide 60 text

/ SCHIBSTED MEDIA GROUP

Slide 61

Slide 61 text

/ SCHIBSTED MEDIA GROUP

Slide 62

Slide 62 text

● Depend on abstractions do not depend on concrete class ● Use design patterns on smart way ● Avoid coupled code and strive for loosely coupled design between objects that interact ● Avoid expensive tasks executed on main thread ● Maintain a clean code style ● Write Clean and Solid Code ● Favor composition over inheritance ● If your code is coupled the Refactor is your friend ● Write test is your responsibility Advices

Slide 63

Slide 63 text

01 02 https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html Uncle Bob - Clean Architecture https://www.youtube.com/watch?v=WpkDN78P884 Uncle Bob - Architecture the lost years 03 Further Reading 04 https://speakerdeck.com/karumi/architecting-your-apps-for-ui-testing Alberto Gragera - Architecting your apps for UI Testing https://erikcaffrey.github.io/ANDROID-clean-architecture/ Erik Jhordan Rey - Clean Architecture

Slide 64

Slide 64 text

Questions?

Slide 65

Slide 65 text

Find me Erik Jhordan González Reyes Mobile Engineer github.com/erikcaffrey [email protected] erikcaffrey.github.io @ErikJhordan_Rey +Erik Jhordan Rey Find me Iván Álvarez Frías Software Engineer github.com/ivanhoe [email protected] iosdevelopers.mx @Ivanhoe +Ivan ??

Slide 66

Slide 66 text

Thank You {NS Coder México}!