Download as PDF, PPTX
Uploaded byBadoo
Clean Architecture
The document outlines the principles of clean architecture in software development, as described by Robert C. Martin, emphasizing the importance of use cases, structure, dependencies, and models. It discusses the organization of architecture into layers and the significance of separating business logic from peripheral concerns. Additionally, it addresses the implementation of clean architecture using various models and demonstrates the use of RxJava for reactive programming within this context.
More Related Content
Clean Architecture
- 1. Keeping it Clean: Cleancode, for dirty developers - Rich King - Senior Android Developer
- 2. 100+ million installs 190countries 100K+ lines of code 185 Activities 23 Services
- 4.
- 5.
- 6.
- 7. And then….. Services ActivitiesEvent BusNetworkGlobal Cache GCM Global Listener DB
- 9.
- 10. So, what isClean Architecture?
- 11. “ A GOODARCHITECTURE EMPHASIZES THE USE-CASES AND DECOUPLES THEM FROM PERIPHERAL CONCERNS — Robert C. Martin
- 12. Clean Architecture • Coinedby Robert C. Martin • Combination of various ideas - Hexagonal Architecture (a.k.a. Ports and Adapters) - Onion Architecture - Screaming Architecture - Data, context and interaction paradigm - Boundary, controller entity objects - Single responsibility principle https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html
- 13. Clean Architecture Key points: 1.Use cases 2.Structure 3.Dependancies 4.Models 5.Testable
- 14. Use cases • Usecases capture business rules Send Message Bob Alice
- 15. What does itdo? • Structure should indicate what the application is, not how it does it.
- 16. What does itdo? • Structure should indicate what the application is, not how it does it. com.myapp activities services presenters content providers views
- 17. What does itdo? • Structure should indicate what the application is, not how it does it. chat conversations com.myapp
- 18.
- 19.
- 20. Inversion of Control ClassA Class B Dependency
- 21. Inversion of Control ClassA Class B Injected
- 22.
- 23.
- 24.
- 25.
- 26. Why different models? UseCase Model •message •id •from Data Model •message •id •from •cacheTime View Model •message •id •from •itemSpacing
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36. interface MessageGateway { List<Message>get(String conversationId); int send(String conversationId, String to, String from, String message); boolean delete(String messageId); void subscribe(Callback callback); } Gateway
- 37. class GetMessages { ... List<M>execute(conversationId) { return mMessageGateway.get(conversationId); } } Use cases
- 38. class SendMessage { ... intexecute(conversationId, ...) { int result = mMessageGateway.send(...); if(result == SUCCESS) mConversationGateway.update(conversationId); return result; } } Use cases
- 39. class SendMessage { ... intexecute(conversationId, ...) { int result = mMessageGateway.send(...); if(result == SUCCESS) mConversationGateway.update(conversationId); return result; } } Use cases
- 40. class SendMessage { ... intexecute(conversationId, ...) { int result = mMessageGateway.send(...); if(result == SUCCESS) mConversationGateway.update(conversationId); return result; } } Use cases
- 41. class MessageScreenPresenter { ... voidonSendMessage(message) { int result = mSendMessage.execute(...); switch (result) { case ERROR: mView.displayError(...) ... } } Presentation
- 42.
- 43. RxJava • Simple toswitch threads • Transformations are convenient • Comes with a cost https://github.com/ReactiveX/RxJava
- 44. mExecutor.post(new Runnable() { voidrun() { // do something mHandler.post(new Runnable() { void run() { // publish result } }); } }); !RxJava
- 45. mExecutor.post(() -> { //do something mHandler.post(() -> { // publish result } } } } !RxJava with lambdas
- 46. doSomething() .observeOn(AndroidSchedulers.mainThread()) .subscribe(result -> /*Handle Result */) RxJava
- 47.
- 48. interface MessageGateway { Single<List<M>>get(...); Single<Integer> send(...); Single<Boolean> delete(...); Observable<Update> subscribe(...); } Gateway
- 49. class GetMessages { ... Single<List<M>>execute(conversationId) { return mMessageRepo.get(conversationId); } } Use cases
- 50. class SendMessage { ... Single<Integer>execute(conversationId, ...) { return mMessageGateway.send(…) .doOnNext(r -> if(r == SUCCESS) mConversationGateway.update(conversationId);) } } Use cases
- 51. class MessageScreenPresenter { ... voidonStart() { mSendMessage.execute(mConversationId) .observeOn(AndroidSchedulers.mainThread()) .filter(result -> result == ERROR) .subscribe(mView::displayError); ... } } Presentation
- 52. class SomeGatewayImpl { Single<Result>load(…) { return loadFromMemory() .flatMap(r -> r != null ? Single.just(r) : loadFromDB()); } } Caching simplified
- 53. class SomeGatewayImpl { Single<Result>load(…) { return loadFromMemory() .flatMap(r -> r != null ? Single.just(r) : loadFromDB()); } } Caching simplified
- 54. class SomeGatewayImpl { Single<Result>load(…) { return loadFromMemory() .flatMap(r -> r != null ? Single.just(r) : loadFromDB()); } } Caching simplified
- 55. class SomeGatewayImpl { Single<Result>load(…) { return loadFromMemory() .flatMap(r -> r != null ? Single.just(r) : loadFromDB()); } } Caching simplified
- 56. class SomeGatewayImpl { Single<Result>load(…) { return loadFromMemory() .flatMap(r -> r != null ? Single.just(r) : loadFromDB()); } } Caching simplified
- 58. Was it worthit? • Boilerplate • Learning curve • Testing • Everything has a place • Decisions can be postponed • Implementations are replaceable
- 59. How can youdo it? • Start small • Discuss and experiment • Tech Talks • Code reviews
- 61.