Clean Architecture: The ONE Change That Transforms Use Cases From Terrible to Super Useful

Summary

This video critically examines the use of 'use cases' in Android development, highlighting common misconceptions and challenges developers face when applying them. The speaker argues that use cases should handle higher-level business logic, not trivial tasks like deleting digits or handling data operations. By emphasizing the importance of business logic and fundamental architectural principles, the video provides valuable insights on creating cleaner, more modular code that aligns with real-world app requirements. It offers a thoughtful perspective on Android architecture, encouraging developers to understand the underlying concepts rather than rigidly following patterns.

Takeaways

• 😀 The speaker discusses the complexities of structuring code in Android development and the use of use cases in architecture.
• 😀 Use cases can be misunderstood and often end up being too complex or misused in the wrong parts of the application.
• 😀 It's important to separate concerns between use cases and the UI layer in an application to maintain clean architecture.
• 😀 Logging analytics events, such as when a to-do item is saved, is valid business logic that belongs in a use case.
• 😀 Direct implementation details (e.g., Firebase classes) should be hidden behind abstractions to keep the use case focused on business logic.
• 😀 The speaker prefers not using use cases in Android development due to their potential for misunderstanding and misuse.
• 😀 Solid architecture can be achieved without using use cases if other architectural principles like modularity and separation of concerns are followed.
• 😀 There is no single best way to structure software, and multiple approaches can be valid as long as they respect core architectural principles.
• 😀 Following basic principles like modular design, SOLID principles, and separation of concerns will help developers adopt any architecture design pattern.
• 😀 The speaker emphasizes understanding foundational architectural principles first, as this makes adopting any design pattern easier and more intuitive.

Q & A

What is the main argument against using use cases in Android applications?

The speaker argues that use cases are often misunderstood and misused in Android applications, leading to unnecessary complexity. Developers frequently wrap simple functions in use cases without adding meaningful business logic, which complicates the architecture without providing real benefits.

What are some examples of logic that shouldn’t be placed in use cases?

Simple operations like deleting a digit from a pin or calling a function like `dropLast()` should not be placed in use cases. These operations don’t represent business logic and are already modular and testable on their own.

What constitutes business logic in the context of Android applications?

Business logic refers to the operations and rules specific to the domain of the application. In a to-do app, for example, business logic might include rules such as 'you cannot mark a to-do as done without a due date.' Business logic encapsulates the core functionality related to the app's user needs.

Why does the speaker believe that use cases are sometimes misunderstood in Android development?

The speaker believes use cases are often misunderstood because many developers treat them as simple wrappers around low-level data functions, when they should represent meaningful business logic that defines the app's core functionality. This results in overly complex architectures without substantial benefits.

How should business logic be structured within an Android app according to the speaker?

Business logic should be placed in use cases if it involves high-level operations specific to the app's domain. For example, tasks like saving a to-do item or registering a user involve business logic and are valid use cases. However, low-level operations like data manipulation should be handled separately.

What is the role of repositories in Android architecture?

Repositories are responsible for managing data sources, such as local storage and remote APIs. They abstract away the details of how data is fetched or saved and provide a clean API for the rest of the application to interact with. Repositories can sometimes overlap with use cases, especially when they involve complex workflows, but they mainly focus on data management.

What does the speaker recommend for logging events in an Android app?

The speaker suggests that logging events, such as saving a to-do item, is valid business logic that can belong in a use case. However, to avoid directly coupling the logic with implementation details, developers should abstract logging behind interfaces, so it doesn’t rely on specific frameworks like Firebase.

How does the speaker view the relationship between use cases and testability?

The speaker sees use cases as helpful for testability when they involve real business logic that can be unit-tested. However, simple operations that don’t define business logic, like data manipulation, don’t benefit from being placed in use cases for testing purposes.

Why does the speaker believe the Essentials course does not use use cases?

In the Essentials course, the speaker opts not to use use cases to demonstrate that a solid architecture can still be built without them. The focus is on fundamental architectural principles, like modular design and separation of concerns, which can be applied without relying on use cases.

What is the speaker's stance on architectural design patterns?

The speaker emphasizes that software architecture is not black and white. There is no single 'best' approach, and different patterns can work depending on the context. However, any approach must adhere to fundamental principles like modular design, SOLID principles, and separation of concerns to be considered valid.