𝙽𝚘𝚝𝚎𝙰𝚙𝚙

𝚃𝚑𝚒𝚜 𝚙𝚛𝚘𝚓𝚎𝚌𝚝 𝚒𝚜 𝚊 𝚜𝚒𝚖𝚙𝚕𝚎 𝚗𝚘𝚝𝚎 𝚊𝚙𝚙𝚕𝚒𝚌𝚊𝚝𝚒𝚘𝚗, 𝚆𝚑𝚎𝚛𝚎 𝚊 𝚞𝚜𝚎𝚛 𝚌𝚊𝚗 𝚌𝚛𝚎𝚊𝚝𝚎 𝚗𝚘𝚝𝚎𝚜, 𝙼𝚘𝚍𝚒𝚏𝚢 𝚝𝚑𝚎 𝚎𝚡𝚒𝚜𝚝𝚒𝚗𝚐 𝚗𝚘𝚝𝚎𝚜 𝚊𝚗𝚍 𝙳𝚎𝚕𝚎𝚝𝚎 𝚎𝚡𝚒𝚜𝚝𝚒𝚗𝚐 𝚗𝚘𝚝𝚎𝚜 𝚜𝚞𝚙𝚙𝚘𝚛𝚝𝚒𝚗𝚐 𝚊𝚕𝚕 𝚝𝚑𝚎 𝙲𝚁𝚄𝙳 𝚘𝚙𝚎𝚛𝚊𝚝𝚒𝚘𝚗𝚜. 𝚃𝚑𝚎 𝚗𝚘𝚝𝚎𝚜 𝚊𝚛𝚎 𝚌𝚊𝚌𝚑𝚎𝚍 𝚘𝚗 𝚝𝚑𝚎 𝚍𝚎𝚟𝚒𝚌𝚎, 𝙱𝚞𝚒𝚕𝚝 𝚘𝚗 𝚊𝚗 𝙼𝚅𝚅𝙼-𝚋𝚊𝚜𝚎𝚍 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎, 𝚊𝚗𝚍 𝚌𝚘𝚖𝚙𝚘𝚜𝚎 𝚊𝚜 𝚝𝚑𝚎 𝚙𝚛𝚎𝚜𝚎𝚗𝚝𝚊𝚝𝚒𝚘𝚗 𝚕𝚊𝚢𝚎𝚛

𝙲𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎 🎈

𝚆𝚑𝚊𝚝 𝚒𝚜 𝚌𝚕𝚎𝚊𝚗 𝚊𝚛𝚌𝚑𝚒𝚝𝚎𝚌𝚝𝚞𝚛𝚎

• 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 mvvm and other and additionally uses use-cases etc
• 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: DeleteNoteUseCase determines this is used to delete a note.
  
• They make code very re-usable, because in the end the view-model call 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 mvvm architecture, we have all the business logic in the view-model
  
• But when we use clean-architecture in combination with mvvm, the business logic is lifted to use-case layer.
  
• 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                

Modes

𝙳𝚊𝚛𝚔 𝙼𝚘𝚍𝚎🌚

𝙽𝚘𝚝𝚎𝚜 𝙻𝚒𝚜𝚝	𝚅𝚒𝚎𝚠 𝙽𝚘𝚝𝚎	𝙴𝚍𝚒𝚝 𝚗𝚘𝚝𝚎

𝙻𝚒𝚐𝚑𝚝 𝙼𝚘𝚍𝚎🌞

𝙽𝚘𝚝𝚎𝚜 𝙻𝚒𝚜𝚝	𝚅𝚒𝚎𝚠 𝙽𝚘𝚝𝚎	𝙴𝚍𝚒𝚝 𝚗𝚘𝚝𝚎

𝙳𝚎𝚖𝚘 🗼

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