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
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.”
15. / SCHIBSTED MEDIA GROUP
Entities
Use Cases
Controllers
Gateways
Presenters
Devices
W
ebUI
DB
External Interfaces
Frameworks and drivers
Interface Adapters
Business Rules
Domain Logic
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
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
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
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
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
28. / SCHIBSTED MEDIA GROUP
View
PresenterViewController
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
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
35. / SCHIBSTED MEDIA GROUP
https://github.com/erikcaffrey/Swift-ModelViewPresenter
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
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
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.
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
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
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
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