The document outlines the SOLID principles of software design, emphasizing concepts like single-responsibility, open-closed, and dependency inversion principles to foster maintainable and scalable architectures. It discusses clean architecture, detailing layers such as entities, use cases, and interface adapters to promote independence from external frameworks and databases. The purpose of clean architecture is to ensure that business rules remain isolated from frequent changes in technology, allowing for a flexible system that can evolve without significant rework.

1. The Clean
Architecture

2. S Single-responsiblity principle
O Open-closed principle
L Liskov substitution principle
I Interface segregation principle
D Dependency inversion principle
Solid Principles

3. Single-responsibility principle
A class should have one and only one reason to change,
meaning that a class should have only one job.
Open-closed principle
Objects or entities should be open for extension, but closed
for modification.

4. Liskov substitution principle
Every subclass/derived class should be substitutable for
their base/parent class.
Interface segregation principle
A class should never be forced to implement an interface
that it doesn't use and a class should never be forced to
implement methods that it doesn't use.

5. Dependency inversion principle
Entities must depend on abstractions not on concretions. It
states that the high level module must not depend on the
low level module, but they should depend on abstractions.

6. vs
Design Pattern
Software Architecture

7. MVC - MVVM - MVP
Design patterns or software architectures?

8. Design pattern
A design pattern is the re-usable form of a solution to a
design problem. (Singleton - Observer - MVC - MVVM -
MVP)
Software architecture
Software architecture refers to the high level structures of a
software system and the discipline of creating such
structures and systems. (Hexagonal architecture - Onion
architecture - The Clean architecture)

9. Successful Software
Architecture
Characteristics

10. Successful Software
Architecture Characteristics
• Testable
• Independent of the UI
• Independent of the Database
• Independent of Frameworks and External Entities

11. Testable
The business logic layer(s) can be tested without the UI, database, net
Independent of the UI
The UI can be easily modified, without changing the rest of the applica

12. Independent of the Database
You can swap out Core Data or SQLite, for Realm, Firebase or
something else entirely. Your business logic is not bound to the
database or persistence layer(s).
Independent of External Entities
The architecture does not depend on external libraries. This allows
the team to use them as tools, rather than having to adapt your
application(s) to their limited constraints and rigid conventions.

13. Why using Clean
Architecture?

14. To make your code:

15. The Clean Architecture

17. Entities are enterprise-wide business rules that encapsulate the most
general business rules, these rules are the least likely to change.
Use cases are also called interactors and stand for application-specific
business rules of the software. This layer is isolated from changes to the
database, common frameworks, and the UI.
Interface adapters convert data from a convenient format for entities and
use cases to a format applicable to databases and the web, for example.
This layer includes Presenters from MVP, ViewModel from MVVM, and
Gateways (also known as Repositories).
Frameworks and drivers are the outermost layer, which consists of the
web framework, database, UI, HTTP client, and so on.

19. - Interactor (Use Case): Contains application specific business rules.
- Entity: Contains application independent business rules.
- Boundary<I>: Data comes into interactors through boundary (interface/protocol) which is implemented by the
interactor. Data goes out from the interactor to boundaries implemented by other objects.
- Delivery Mechanism: Can be Web, Console application, Mobile App UI, etc

20. 1- User clicks a button (on a web form for example).
2- The delivery mechanism (ex: Web) takes whatever data submitted by the user and stick it into a data
structure which contains only primitives types (Request Model).
3- The request model passed through the input boundary and since the interactor implements the input
boundary, the interactor received that request model.

21. 4- Interactor then uses that request model and controls the dance of the entities (ex: creates the order,
modify the customer, etc).

22. 5- And when it’s done with that, it continues to control the dance of the entities but this time in the opposite
direction as it gather up all the results to create yet another data structure called (Response Model).

23. 6- The response model is passed back out through the output boundary to the delivery mechanism that
implement it and somehow it’s delivered to the user.

25. -Response Model contains data that was created by the interactor as the result of the use
case, but this data is not presentable, a date for example would be a date object, and the
currency would be a money object.
-Presenter is a class or a set of classes whose job is to take the response model and translate
it into a view model. For example, it takes the date object from the response model and calls
simple data formatter which generates a nice date string that the view model will hold, and
takes the currency from the response model and puts the currency symbol in the view model.
-View Model contains the data that will be used by the view. For example, If there is a button on
the view, the view model has the string that holds the name of that button, and if the button
shouldn’t be active, so it should be grey, the view model holds the boolean that indicates the
status of the button. If there are menu items in the view, the view model has the names of all
the menu items and their order.
-View all it can do is grabbing the data from the view model and put it on the screen. It should
be so stupid so you don’t have to test it. (You can test it with your eyes).

26. What about the
database?

27. –Robert C. Martin
“If something changes a lot, it should be a plug-in. If
something doesn’t change very often, it should be
plugged into.”

28. What about the database?
• The database is a detail, it shouldn’t be the center of your
architecture.
• The database should be a plug-in to the business rules.
• Business rules shouldn’t be written in stored procedures in
the database.

31. Real Life Example

32. List contacts use case
• List all the contacts from the local database and from the
phone database.
• Group the contacts by mobile number and remove the
duplicates.
• Present the filtered contacts in a table view.

34. Questions?

35. References:
• https://www.youtube.com/watch?v=o_TH-Y78tt4
• https://proandroiddev.com/clean-architecture-data-flow-dependency-rule-
615ffdd79e29
• https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-
architecture.html
• https://medium.freecodecamp.org/a-quick-introduction-to-clean-architecture-
990c014448d2
• https://medium.com/@pxpgraphics/clean-architecture-3fe6907e7441
• https://hackernoon.com/golang-clean-archithecture-efd6d7c43047
• https://rubygarage.org/blog/clean-android-architecture

36. Thank You!