Content:
- Architecture
- Philosophy
- Concept
- What is Clean Architecture?
- Layers
- Example
- FAQ
- How does Clean Architecture improve software development?
- Can Clean Architecture be used with any programming language?
- Is Clean Architecture applicable only for large-scale applications?
- How is data validation handled in Clean Architecture?
- How are errors handled in Clean Architecture?
- What are Interactors in Clean Architecture?
- How do you deal with performance in Clean Architecture?
- Is Clean Architecture the same as Hexagonal Architecture?
- Useful links
- Project structure and Modularity
- Tech Stack
Remember ☝️
Architecture is a crucial part of developing software, but it's not a dogma.
Architecture is a set of recommendations to save you from trivial mistakes and make life easier, but if for your purpose you need to break it - you can do it.
This project follows the architectural concept of The Clean Architecture:
It is an architectural approach that emphasizes the separation of concerns, the use of dependency inversion, and the creation of testable and maintainable code.
It promotes flexibility by separating the application into different layers of abstraction.
This allows for easier maintenance and testing of individual components, as well as the ability to swap out underlying technologies without affecting the overall architecture.
Architecture was popularized by Robert C. Martin ("Uncle Bob").
Usually, implementation consists of the following three layers/packages/folders: Presentation, Domain, and Data.
Presentation is all about Displaying data, User input handling, Data validation, and Navigation.
If the Presentation Layer needs data or business logic, it calls Domain Layer.
The Domain layer, also known as the Business layer, is a key component that focuses on the core business logic, rules, and entities specific to the problem domain the application is designed to address.
The Domain layer is independent of any technology or infrastructure concerns, such as databases, user interfaces, or external services.
This separation allows the business logic to be more easily understood, maintained, and tested, without being affected by changes in other layers or components of the application.
The Data layer, or the Persistence layer, is a component of an application's architecture responsible for managing data storage, retrieval, and manipulation. This layer serves as an abstraction between the application's core logic and the underlying data storage technology, such as databases, file systems, or external APIs.
Examples can be found in most project modules, but let's take a look at the Course module.
For instance, here we can find the next structure:
CourseOutlineFragment and CourseOutlineViewModel as a representation of the Presentation Layer.
CourseInteractor as a representation of the Domain Layer.
And CourseRepository as a representation of the Data Layer.
The best way to determine what a module does is to open its Interactor.
Here you can find all the business cases covered by the module.
But if you want to know how it does it, you must delve into its Presentation and Data layers.
Clean Architecture separates the concerns of software components, reduces coupling, and improves the independence of software systems.
This makes the system more flexible, maintainable, and testable. It also ensures that the software can survive changes in technology, user interface, and even some business rules.
Yes, Clean Architecture is not tied to any specific programming language.
It's a design philosophy that can be applied to any language as long as it supports the principles of object-oriented design.
No, Clean Architecture is not exclusively for large-scale applications.
It can be implemented in small projects as well, providing similar benefits of maintainability, scalability, and testability.
However, for very simple or small-scale applications, implementing Clean Architecture might be overkill and lead to unnecessary complexity.
Data validation can be considered at various levels in Clean Architecture. Simple, technical validations like checking for null or validating data formats can be done in the outer layers. Business rule validations, on the other hand, should be handled by Entities or Use Cases in the inner layers. This helps to ensure that invalid data never reaches the core business logic.
Error handling in Clean Architecture typically depends on the type of error.
Domain-specific errors (those that relate to the core business rules) should be handled within the Entities or Use Cases.
Technical errors (like a database connection failing) should be handled at the outer layers, with the necessary information relayed back to the inner layers through predefined interfaces.
Interactors, also known as Use Cases, represent specific applications of the business rules.
They orchestrate the flow of data between Entities and the outer layers of the system.
Interactors contain the logic to fulfill each use case of the system and maintain a decoupled relationship with the Entities and outer layers via interfaces.
While Clean Architecture is not specifically designed to optimize performance, it does not inherently cause performance issues either.
If performance becomes a concern, then performance optimization strategies can be applied in the relevant layers or components.
However, it is recommended to keep these optimizations isolated from the business rules to preserve the separation of concerns.
While there are similarities between Clean Architecture and Hexagonal Architecture (also known as Ports and Adapters) in terms of their goal of separation of concerns and testability, they are not the same.
Both architectures advocate for isolating business logic from external concerns, but they use different metaphors and structures.
Clean Architecture tends to focus more on layers, while Hexagonal Architecture emphasizes the interaction points (ports) and their implementations (adapters).
If you want to delve deeper into the topic of CA, you can find useful links below.
Article: Clean Architecture for mobile: To be, or not to be
Video: Robert C Martin - Clean Architecture and Design
Book: Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin Series)
Modular architecture in applications pertains to the practice of decomposing an app's elements into smaller, reusable, and interchangeable modules.
Each Feature in the application is represented by a specific module, so you will not have problems finding the right class or functionality.
Lower modules don't know anything about the higher modules.
It helps avoid conflicts with circular dependencies.
If you need to pass some logic from one independent module to another, it is not a good idea to link modules to each other, this will eventually lead to circular dependencies and the broken project.
The better way is an abstraction in the core, implementation in the module, and dependency injection.
Each module is centered around a specific set of features or functionality.
- App module - app lifecycle management, routing, dependency control.
- Auth Module - anything related to the user authorization process.
- Discovery Module - anything related to the course catalog and search.
- Dashboard Module - anything related to the course dashboard.
- Profile Module - anything related to a user profile and settings.
- Course Module - anything related to course structure, certificates, and assessments.
- Discussion Module - anything related to course discussions.
- Core Module - a set of utilities and abstractions required by each module.
Modular approach has several benefits such as:
By separating components into modules, developers can better understand and manage the structure of the codebase.
This organization facilitates code navigation and makes it easier to locate specific functionalities.
Since modules are self-contained, it's easier to add or remove features as the application grows.
This flexibility allows developers to build scalable apps that can evolve with changing requirements.
Modular architecture promotes the creation of reusable components, which can be easily shared across multiple projects or within different parts of the same project.
This reusability can lead to increased productivity and reduced development time.
Modular architecture allows incremental builds, where only the modified modules are recompiled.
This approach can significantly reduce build times and improve the development workflow.
- Go to File -> New -> New Module...
- Select Android Library from Templates, change your module name and click the Finish button.
- For the final step don't forget to add core module dependency to your module and add your module to the App module.
The project tries to use only the required number of libraries and frameworks and avoid unnecessary dependencies.
The following technologies are used in the project:
- Kotlin, the main programming language
- Kotlin Coroutines, the main toolkit for managing async jobs.
- AndroidX set of libraries, a necessary part of modern Android applications.
- Jetpack Compose, the main toolkit for building UI.
- Retrofit2, a type-safe HTTP client for Android and Java.
- Room, abstraction layer over SQLite.
- Koin, dependency injection framework.
- Koil, images loading library.
- Firebase, infrastructure.
- JUnit, unit testing framework.
- Mockk, mocking library for Kotlin.