Save 37% off PRO during our Black Friday Sale! »

Clean Architecture IOS

Clean Architecture IOS

We know that writing quality software is hard and complex: It is not only about satisfying requirements, also should be maintainable, testable, and flexible enough to adapt to growth and change.
Clean architecture comes up and could be a good approach for using when developing any software application.


Erik Jhordan Rey

February 22, 2017


  1. Clean Architecture Iván Álvarez Frías Erik Jhordan González Reyes

    @Ivanhoe @ErikJhordan_Rey
  2. “Clean code always looks like it was written by someone

    who cares”
  3. IOS Smells

  4. / 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

  6. / SCHIBSTED MEDIA GROUP STUPID Singleton Invasion Tight Coupling Untestability

    Premature Optimization Indescriptive Naming Duplication

    are principles, not laws!

  9. SOLID

  10. / SCHIBSTED MEDIA GROUP SOLID Single Responsibility Principle Open /

    Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  11. “Depend upon abstractions. Do not depend upon concrete classes”

  12. Architecture

  13. / 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.”
  14. Clean Architecture

  15. / 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
  16. Dependency Rule

  17. / 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
  18. Entities

  19. / 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
  20. Use Cases

  21. / 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
  22. Interface Adapters

  23. / 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
  24. Frameworks and Drivers

  25. / 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
  26. IOS Clean architecture


  28. / 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
  29. Presentation Layer



    UI Design Patterns
  32. 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.
  33. 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.
  34. Model View Presenter View Presenter Model User interaction notify user

    event request data Update UI with entities delivers entities

  36. 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.
  37. Model View ViewModel View ViewModel Model DataBinding and Commands ViewModel

    updates the model Send Notifications Send Notifications
  38. / SCHIBSTED MEDIA GROUP What Do They have in common?

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

  40. / SCHIBSTED MEDIA GROUP What pattern Should I use?

  41. / 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
  42. Domain Layer

  43. / SCHIBSTED MEDIA GROUP • Contains Business Logic • No

    Code specific to a framework • Use Command Pattern (optional) Domain
  44. / 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.
  45. Data Layer

  46. / 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
  47. / SCHIBSTED MEDIA GROUP Data Mapper Repository Client Business Logic

    Business Entity Business Entity Persist Query Query Object Data Source
  48. / 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
  49. / 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
  50. / 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
  51. Solution ….

  52. Dependency Injector

  53. / 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
  54. / 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
  55. / 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
  56. Routing

  57. / SCHIBSTED MEDIA GROUP Routing • Segues • TabBarViewController •

    NavigationViewController • Push • Search Solution • Navigator • Wireframe
  58. Show me code!




  62. • 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
  63. 01 02 Uncle Bob - Clean Architecture Uncle

    Bob - Architecture the lost years 03 Further Reading 04 Alberto Gragera - Architecting your apps for UI Testing Erik Jhordan Rey - Clean Architecture
  64. Questions?

  65. Find me Erik Jhordan González Reyes Mobile Engineer @ErikJhordan_Rey +Erik Jhordan Rey Find me Iván Álvarez Frías Software Engineer @Ivanhoe +Ivan ??
  66. Thank You {NS Coder México}!