From Clean Architecture to Modular Patterns

https://www.youtube.com/playlist?list=PLT2xIm2X7W7gqbDpY2FXCnRC5yaD3dVQS

Transcript

1. From Clean Architecture 
 to Modular Patterns Saeed Masoumi
3. Who Am I ?
5. Architecture
6. Architecture [ahr-ki-tek-cher] (n.) the structure and design of a system or product
11. • Pumping System • Electric Power System • Sewage Treatment System • and many other components …
14. Blueprint of a restaurant sewage treatment system
15. Blueprint of a restaurant sewage treatment system
16. Blueprint of a restaurant
17. Blueprint of a restaurant • The architecture of the building tells you not what it’s made of. What it tells you is intent. • The architecture would scream: Restaurant (screaming architecture)
18. Architecture
19. Architecture • Architecture is about intent
20. Architecture • Architecture is about intent • Architecture is about use-cases
21. Architecture • Architecture is about intent • Architecture is about use-cases • MVP, MVVM, RxJava, Dagger, Retrofit, … these are tools, not architecture
22. Clean Architecture
23. Clean Architecture • Core concepts been around for decades • Has coined since 2012 by Uncle Bob
24. Clean Architecture
25. Clean Architecture Entities Use Cases Controllers Gateways Presenters Android W eb UI External Interfaces DB
26. Entities Entities
27. Entities Entities
28. Entities • Application independent business rules
 (domain module) Entities
29. Entities • Application independent business rules
 (domain module) • Can be an object with methods, or it can be a set of data structures and functions Entities
30. Entities • Application independent business rules
 (domain module) • Can be an object with methods, or it can be a set of data structures and functions • Least likely to change when something external changes Entities
31. Entities • Application independent business rules
 (domain module) • Can be an object with methods, or it can be a set of data structures and functions • Least likely to change when something external changes • For a single application, these entities are the business objects Entities
32. Interactors Use Cases
33. Interactors Use Cases
34. Interactors Use Cases • Application specific Business Rules 
 (application module)
35. Interactors Use Cases • Application specific Business Rules 
 (application module) • A description of an action that a user performs 
 on a system and tells the entity what to do
36. Interactors Use Cases • Application specific Business Rules 
 (application module) • A description of an action that a user performs 
 on a system and tells the entity what to do • We don’t care about details
37. Interactors Use Cases • Application specific Business Rules 
 (application module) • A description of an action that a user performs 
 on a system and tells the entity what to do • We don’t care about details • The result can be delivered to a web page or a mobile app …
38. Interactors Use Cases • Application specific Business Rules 
 (application module) • A description of an action that a user performs 
 on a system and tells the entity what to do • We don’t care about details • The result can be delivered to a web page or a mobile app … • Similar to the command pattern
39. Interactors Use Cases
40. Interface Adapters Controllers Gateways Presenters
41. Interface Adapters Controllers Gateways Presenters
42. Interface Adapters Controllers Gateways Presenters • 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/Android …
43. Interface Adapters Controllers Gateways Presenters • 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/Android … • Entity-Boundary-Interactor Architecture
44. Interface Adapters Controllers Gateways Presenters • 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/Android … • Entity-Boundary-Interactor Architecture • Input/Output boundaries
45. Interface Adapters Controllers Gateways Presenters • 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/Android … • Entity-Boundary-Interactor Architecture • Input/Output boundaries • MV-whatever lives here
46. Frameworks & Drivers Android W eb UI External Interfaces DB
47. Frameworks & Drivers Android W eb UI External Interfaces DB
48. Frameworks & Drivers Android W eb UI External Interfaces DB • A delivery mechanism,
 Where all the details go
49. Frameworks & Drivers Android W eb UI External Interfaces DB • A delivery mechanism,
 Where all the details go • Database, the App Frameworks …
51. So what is the Clean Architecture?
53. The Dependency Rule
54. The Dependency Rule Mechanism Policies
55. The Dependency Rule
56. The Dependency Rule • Independent of frameworks
57. The Dependency Rule • Independent of frameworks • Testable
58. The Dependency Rule • Independent of frameworks • Testable • Independent of UI
59. The Dependency Rule • Independent of frameworks • Testable • Independent of UI • Independent of Database
60. The Dependency Rule • Independent of frameworks • Testable • Independent of UI • Independent of Database • Independent of any external agency
62. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
63. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
64. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
65. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
66. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
67. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
68. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
69. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
70. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
71. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
72. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
73. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
74. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
75. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
76. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
77. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
78. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
79. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
80. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
81. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
82. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
83. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
84. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
85. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
86. UseCase Presenter ViewModel View Entities Repository Repository Entities Entities DataSource DataSource Android Stuff DataSourceImpl DataSourceImpl
88. App Structure
89. App Structure MyAwesomeApp business-logic application-domain presentation data android front
90. But there is a problem here!!!
92. Challenges in Mobile App Development
93. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps.
94. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc)
95. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc) • Enterprise applications ( Tap30, Snapp, DigiKala … )
96. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc) • Enterprise applications ( Tap30, Snapp, DigiKala … ) • Team growth
97. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc) • Enterprise applications ( Tap30, Snapp, DigiKala … ) • Team growth • Large Codebase
98. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc) • Enterprise applications ( Tap30, Snapp, DigiKala … ) • Team growth • Large Codebase • Deliver features fast without fuss
99. Challenges in Mobile App Development • Most of the use-cases are just for data consuming, So mobile apps do very little than web apps. • Most of the time we deal with the platform issues ( memory, storage, lifecycle hell, location services, etc) • Enterprise applications ( Tap30, Snapp, DigiKala … ) • Team growth • Large Codebase • Deliver features fast without fuss • Also need an architecture for Test!!
101. 
 Clean Architecture could be a little bit over-engineered
103. Modular Pattern
104. Modular Pattern • Cut the large monolith software into many vertical smaller monoliths (similar to microservices architecture)
105. Modular Pattern • Cut the large monolith software into many vertical smaller monoliths (similar to microservices architecture) • Each team only needs to focus on the module that they work
106. Modular Pattern • Cut the large monolith software into many vertical smaller monoliths (similar to microservices architecture) • Each team only needs to focus on the module that they work • Organize your code as it grows
108. Independent Modules
109. Independent Modules • extensible, reusable, maintainable, and adaptable.
110. Independent Modules • extensible, reusable, maintainable, and adaptable. • flexible composite of collaborating modules
111. Independent Modules • extensible, reusable, maintainable, and adaptable. • flexible composite of collaborating modules • Helps on-boarding process for new developers
113. So let’s combine them
115. Modern App Architecture
116. Modern App Architecture • Again follow the dependency rule!
117. Modern App Architecture • Again follow the dependency rule! • Break the rules based on your need
118. Modern App Architecture • Again follow the dependency rule! • Break the rules based on your need • Unidirectional data flow architecture, like Flux
119. Modern App Architecture • Again follow the dependency rule! • Break the rules based on your need • Unidirectional data flow architecture, like Flux • Easy to learn
120. Modern App Architecture • Again follow the dependency rule! • Break the rules based on your need • Unidirectional data flow architecture, like Flux • Easy to learn • Testable
121. Modern App Architecture • Again follow the dependency rule! • Break the rules based on your need • Unidirectional data flow architecture, like Flux • Easy to learn • Testable • Use BoundedContext Pattern
123. How did we scale our app in Tap30?
125. Our Main Challenges
126. Our Main Challenges • Team growth
127. Our Main Challenges • Team growth • More features demand from business side
128. Our Main Challenges • Team growth • More features demand from business side • Large codebase
129. Our Main Challenges • Team growth • More features demand from business side • Large codebase • Need a platform team
131. What we did…
132. What we did… • Combine the idea behind Flux and the clean architecture principles to create a unidirectional and state-based data flow architecture
133. What we did… • Combine the idea behind Flux and the clean architecture principles to create a unidirectional and state-based data flow architecture • Convert our driver & frameworks layer to a single independent modules (e.g. location, persistence, etc)
134. What we did… • Combine the idea behind Flux and the clean architecture principles to create a unidirectional and state-based data flow architecture • Convert our driver & frameworks layer to a single independent modules (e.g. location, persistence, etc) • Increase the level of abstraction
135. What we did… • Combine the idea behind Flux and the clean architecture principles to create a unidirectional and state-based data flow architecture • Convert our driver & frameworks layer to a single independent modules (e.g. location, persistence, etc) • Increase the level of abstraction • Use BoundedContext pattern
137. Applying BoundedContext Pattern
138. PreRequestContext
139. PreRequestContext
140. PaymentContext
141. PaymentContext
143. Shared Architecture and Business Logic PreRideContext RideContext PaymentContext UserManagementContext Platform/SDK Modules Test Platform Twister
145. How does it work?
146. How does it work? • Shared Architecture contains our internal libraries, architecture, etc. • Each BoundedContext is a mini-app and contains all layers from presentation to data • Each Platform module binds to a BoundedContext and add extra functionality • Test platform helps us to test specific/whole parts of the app • Twister is an app bootstrap and binds all needed modules to create our Passenger/Driver apps.
147. Thanks