Home repo

Domain Layer

09:07

Summary

This lesson introduces the Repository Pattern within the Domain layer by creating an abstract repository class for the Home feature. It explains the conceptual role of the Domain layer as the "architect" that defines what operations an application can perform without worrying about how they are implemented. By analyzing the UI requirements, the instructor demonstrates how to define abstract methods that return collections of BookEntity objects, solidifying the dependency rule where repositories must rely on entities.

Key Ideas

Repositories in the Clean Architecture diagram visually straddle the Domain and Data layers, illustrating the Repository Pattern.
Domain layer repositories are strictly abstract classes that define contracts (what will happen), not implementations (how it will happen).
The Domain layer acts like an architectural blueprint specifying features, while the Data layer acts as the builders executing the logic.
Repository methods must return Domain layer Entities, dictating that Entities must be created before Repositories.
UI analysis determines the repository contract; the HomeRepo defines two core operations: fetching featured books and fetching the newest books.
abstract class is used to create the blueprint because we do not want to define the method bodies in the Domain layer.

Code Snippets

lib/features/home/domain/repos/home_repo.dartdart

import 'package:bookly_app/features/home/domain/entities/book_entity.dart';

abstract class HomeRepo {
  Future<List<BookEntity>> fetchFeaturedBooks();
  Future<List<BookEntity>> fetchNewestBooks();
}

Architecture Insight

Architecture insight

The repository in domain/ is only a contract — an abstract class listing the operations the rest of the app can ask for. The concrete HomeRepoImpl lives in data/ and depends on the contract, not the other way around. That inversion is the entire reason CA can swap data sources without touching use cases.

A useful sanity check: read the contract out loud. "Fetch featured books." That's a business intent. If you ever see fetchFromCacheIfRecentElseFromApi in the contract, the contract has leaked implementation details — push those decisions into the impl.

Looking ahead — The either-class lesson refactors these return types to Either<Failure, ...> — the contract becomes total instead of partial.

My Notes

The instructor's analogy comparing the Domain layer to "architects" (defining the blueprint) and the Data layer to "builders" (implementing the concrete logic) is a fantastic mental model for understanding the Dependency Inversion Principle.

Gotcha: The instructor defined the abstract methods to return Future<List<BookEntity>>. While functionally correct for a basic setup, this forces the Presentation layer (Bloc/Cubit) to use try-catch blocks to handle network or database exceptions.
[Editor's note] A stricter Clean Architecture approach wraps the return type in an Either construct (e.g., Future<Either<Failure, List<BookEntity>>>). This forces the calling code to explicitly handle both the success (Right) and error (Left) states. It is highly likely the instructor will refactor this to use Either in a future lesson when handling failures, but it is important to anticipate this shift now.