Clean Architecture

Clean ArchitectureIván Álvarez FríasErik Jhordan González Reyes

[email protected]@Ivanhoegithub.com/ivanhoe

[email protected]@ErikJhordan_Rey github.com/erikcaffrey

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

IOS Smells

/ 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

STUPID


STUPID

Singleton InvasionTight CouplingUntestabilityPremature OptimizationIndescriptive NamingDuplication


From STUPID to SOLID codeThese are principles, not laws!


SOLID


SOLID

Single Responsibility PrincipleOpen / Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle

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

Architecture


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

Clean Architecture


Entities

Use Cases

Controllers

Gateways

Presen

ters

Devi

ces

Web

UIDB

External Interfaces

Frameworks and drivers

Interface Adapters

Business Rules

Domain Logic

Dependency Rule


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

Entities


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

Use Cases


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

Interface Adapters


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

Frameworks and Drivers


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

IOS Clean architecture


VIPER


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

Presentation Layer



● MVC● MVP● MVVM

UI Design Patterns

Talk Schedule

Model View Controller

Model What to display?

View How it’s displayed?

ControllerFormatting the model for display and handling events like user input.

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.

Model View Presenter

View Presenter Model

User interaction

notify user event request data

Update UI with entities

delivers entities


https://github.com/erikcaffrey/Swift-ModelViewPresenter

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.

Model View ViewModel

View ViewModel Model

DataBinding and Commands

ViewModel updates the model

Send Notifications

Send Notifications


What Do They have in common?

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


What pattern Should I use?


● 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

Domain Layer


● Contains Business Logic

● No Code specific to a framework

● Use Command Pattern (optional)

Domain


Command PatternHolding 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.

Data Layer


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


Data Mapper

RepositoryClient

Business Logic

Business Entity

Business Entity

Persist

Query

Query Object

Data Source


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


● 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


● 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

Solution ….

Dependency Injector


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


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


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

Routing


Routing● Segues● TabBarViewController● NavigationViewController● Push● Search

Solution

● Navigator● Wireframe

Show me code!




● 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

01

02

https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.htmlUncle Bob - Clean Architecture

https://www.youtube.com/watch?v=WpkDN78P884Uncle Bob - Architecture the lost years

03

Further Reading

04

https://speakerdeck.com/karumi/architecting-your-apps-for-ui-testingAlberto Gragera - Architecting your apps for UI Testing

https://erikcaffrey.github.io/ANDROID-clean-architecture/

Erik Jhordan Rey - Clean Architecture

Questions?

Find me

Erik Jhordan González ReyesMobile Engineer

github.com/erikcaffrey

[email protected]

erikcaffrey.github.io

@ErikJhordan_Rey

+Erik Jhordan Rey

Find me

Iván Álvarez FríasSoftware Engineer

github.com/ivanhoe

[email protected]

iosdevelopers.mx

@Ivanhoe

+Ivan ??

Thank You

{NS Coder México}!

Date post:	13-Apr-2017
Category:	Software
Upload:	nscoder-mexico
View:	129 times
Download:	1 times