𝚃𝚑𝚒𝚜 𝚙𝚛𝚘𝚓𝚎𝚌𝚝 𝚒𝚜 𝚊 𝚜𝚒𝚖𝚙𝚕𝚎 𝚗𝚘𝚝𝚎 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗, 𝚆𝚑𝚎𝚛𝚎 𝚊 𝚞𝚜𝚎𝚛 𝚌𝚊𝚗 𝚌𝚛𝚎𝚊𝚝𝚎 𝚗𝚘𝚝𝚎𝚜, 𝙼𝚘𝚍𝚒𝚏𝚢 𝚝𝚑𝚎 𝚎𝚡𝚒𝚜𝚝𝚒𝚗𝚐 𝚗𝚘𝚝𝚎𝚜 𝚊𝚗𝚍 𝙳𝚎𝚕𝚎𝚝𝚎 𝚎𝚡𝚒𝚜𝚝𝚒𝚗𝚐 𝚗𝚘𝚝𝚎𝚜 𝚜𝚞𝚙𝚙𝚘𝚛𝚝𝚒𝚗𝚐 𝚊𝚕𝚕 𝚝𝚑𝚎 𝙲𝚁𝚄𝙳 𝚘𝚙𝚎𝚛𝚊𝚝𝚒𝚘𝚗𝚜. 𝚃𝚑𝚎 𝚗𝚘𝚝𝚎𝚜 𝚊𝚛𝚎 𝚌𝚊𝚌𝚑𝚎𝚍 𝚘𝚗 𝚝𝚑𝚎 𝚍𝚎𝚟𝚒𝚌𝚎, 𝙱𝚞𝚒𝚕𝚝 𝚘𝚗 𝚊𝚗 𝙼𝚅𝚅𝙼-𝚋𝚊𝚜𝚎𝚍 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎, 𝚊𝚗𝚍 𝚌𝚘𝚖𝚙𝚘𝚜𝚎 𝚊𝚜 𝚝𝚑𝚎 𝚙𝚛𝚎𝚜𝚎𝚗𝚝𝚊𝚝𝚒𝚘𝚗 𝚕𝚊𝚢𝚎𝚛
- Having one concern per component, Meaning each piece of our architecture does only one thing and nothing else. If one component is doing more than one thing, we need to split them
- It is structured layered dependency. It is not specific to mobile development instead its software development architecture.
- Clean architecture term comes from Uncle bob, He created this methodology for building software products.
- It actually uses existing architectures like
mvvmand other and additionally usesuse-casesetc - It makes your applicaiton scalable majorly involves, how easy it is to replace a layer of application without breaking the other layers.
- A large code base comes with challenge of structuring it which involves how easy it is to extend it, test the functions in it, understand it
Advantages |
How its useful |
|---|---|
Strict architecture |
Because of how the layers of code are organized it is not easy to make mistakes |
Encapsulation |
Each layer is organized into its own part having its own responsibility |
Parallel development |
If we have each feature in module wise each of the modules are built parallely |
Highly scalable |
Once organized properly, we can grow a small project into large one without bumping to problems |
Simple and easy |
Due to single responsibility its way easier to understand each snipped of code on what it does |
Testing |
Since all the layers are decoupled, we can write unit tests on them easily |
𝚂𝚒𝚗𝚐𝚕𝚎 𝚛𝚎𝚜𝚙𝚘𝚗𝚜𝚒𝚋𝚒𝚕𝚒𝚝𝚢 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎
- A class should have only one job.
- A class should have only one reason to change.
- If the class has two reasons to change, Then the class has to be split up into two components.
𝙾𝚙𝚎𝚗 𝙲𝚕𝚘𝚜𝚎𝚍 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎
- It should be open for extension, but closed for modification.
- If new functionality needs to be added, it should be added as an extension of the class.
- This allows us to abstract the stable functionality.
- If functionality is working and stable and we add a new feature on top of the existing feature for it. Now we will have stable functionality always working.
- Thus the volatile functionality will be in the extended classes and the stable functionality in the extended classes.
𝙻𝚒𝚜𝚔𝚘𝚟 𝚜𝚞𝚋𝚜𝚝𝚒𝚝𝚞𝚝𝚒𝚘𝚗 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎
- Lower level classes can be substituted without affecting higher levels.
- This is achieved using abstract classes and interfaces.
𝙸𝚗𝚝𝚎𝚛𝚏𝚊𝚌𝚎 𝚜𝚎𝚐𝚛𝚎𝚐𝚊𝚝𝚒𝚘𝚗 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎
- We use an interface to advertise the functionality.
- Many specific interfaces are better than a generic interface.
- Interface just exposes the methods the dependent classes needed and nothing else.
𝙳𝚎𝚙𝚎𝚗𝚍𝚎𝚗𝚌𝚢 𝚒𝚗𝚟𝚎𝚛𝚜𝚒𝚘𝚗 𝚙𝚛𝚒𝚗𝚌𝚒𝚙𝚕𝚎
- Concrete classes depend on abstract classes and not the other way around.
- Volatile and stable functionalities are encapsulated, having the dependency relationship between the two.
- Framework-specific functionality depends on business logic with a dependency between them.
𝚁𝚎𝚙𝚘𝚜𝚒𝚝𝚘𝚛𝚢:
- Here in the project we have database, We use the database and call the functions of DAO in our repository.
- The repository directly accesses our datasources, wither API or database.
- The repository takes these datasources and determine which data has to be forwarded to the corrosponding use-cases.
- Say if you have two data sources(API,Cache), The repository needs to determine, do we load the data fro API or the cache.
- The decesion logic of determing the choosing of data source and determining if there is any errors during this.
𝚄𝚜𝚎𝙲𝚊𝚜𝚎𝚜:
- Use-cases shouldn't know where the repository gets the data from.
- They just get the data and thats it.
- Contains the business logic.
- Makes code very redable, Because essentially the use-case is is something that does one thing.
- We can just know what a class does by just reading the name of the class. Ex:
DeleteNoteUseCasedetermines this is used to delete a note. - They make code very re-usable, because in the end the
view-modelcall the use-cases. - If you implement the all the business logic in view-model and say if you need that logic in a different view model its not possible, Using a use-case overcomes this by re-using hte use-case class in a different view-model.
𝚁𝚎𝚙𝚘𝚜𝚒𝚝𝚘𝚛𝚢 𝚍𝚎𝚏𝚒𝚗𝚒𝚝𝚒𝚘𝚗 𝚒𝚗 𝚝𝚑𝚎 𝚍𝚘𝚖𝚊𝚒𝚗 𝚕𝚊𝚢𝚎𝚛:
- This is useful because we can create fake versions of the repository for testing
- We can pass fake repository to use cases for testing so that use cases won't know where the data is coming from
- Say its from a real repository or a local json file, They just get data and do something from it
𝚅𝚒𝚎𝚠-𝙼𝚘𝚍𝚎𝚕:
- When we just use a
mvvmarchitecture, we have all the business logic in theview-model - But when we use
clean-architecturein combination withmvvm, the business logic is lifted touse-caselayer. - So the view model puts some inputs to a use-case and performs some computation based on the input and gets the result and delegates the resut as a state to the presentation(UI) layer.
Project Folder
.
├── app
| |
│ ├──> DI
| |
│ |──> Feature
| | |
| | |──-------------> Data
| | | |
| | | |──-------------> DataSource
| | | |
| | | └──-------------> Repository
| | |
| | |──-------------> Domain
| | | |
| | | |──-------------> Model
| | | |
| | | |──-------------> RepositoryDefinition
| | | |
| | | |──-------------> UseCase
| | | |
| | | └──-------------> Util
| | |
| | └──-------------> Presentation
| | |
| | |──-------------> Screen1
| | | |
| | | |
| | | └──-------------> Components
| | |
| | └──-------------------------------> MainActivity
| |
| |──> UI
| | |
| | └──--------------------------------------------------> Theme
| |
│ └──-------------------------------------------------------> ApplicationClass
Demo.mp4
If you feel like support me a coffee for my efforts, I would greatly appreciate it.
Read contribution guidelines for more information regarding contribution.
Feature requests are always welcome, File an issue here.
Support it by clicking the ⭐ button on the upper right of this page. ✌️
This project is licensed under the Apache License 2.0 - see the LICENSE file for details
