Open In App

Domain Layer in Android

Improve
Improve
Like Article
Like
Save
Share
Report

Data preparation for the UI layer is done at the domain layer. If we think of this layer as a “black box,” the data model particular to the source that was established by the API or database serves as its input. A UI model that is ready to be used by the UI layer is the output of the domain layer. In this article, we will look at how to use the Domain Layer, which is a middle layer between the UI and the data to better develop our apps.

It also works the other way around. Models from the data layer are recognized, arranged, and given some logic. A change in the data layer (such as switching from JSON API to HAL) should infrequently have an impact on the UI layer because the Domain layer handles all data cleaning and preparation.

What is the Domain Layer?

Between the UI layer and the data layer is the domain layer, which is an optional layer. Complex business logic or simple business logic that is utilized by several ViewModels must be contained in the domain layer. Because not all apps will meet these requirements, this layer is optional. Use it only as necessary, such as to manage complexity or favor reusability. Look at the figure below to understand what Domain Layer logically means:

Understanding the concept of the Domain Layer

Image #1: Understanding the concept of the Domain Layer

What advantage does the Domain Layer Serve:

  1. It raises the app’s testability.
  2. Duplication of code is prevented.
  3. It makes classes that use domain layer classes easier to read.
  4. By allowing you to divide up the responsibilities, it prevents big classes.

GeekTip: Each use case should only be in charge of a single functionality for the sake of simplicity and portability, and they shouldn’t contain mutable data. As an alternative, you should manage mutable data in your UI or data layers.

Requirements to Have a Domain Layer

Use case classes are positioned between ViewModels from the UI layer and repositories from the data layer in a typical app architecture. This means that use case classes typically rely on repository classes, and they interact with the UI layer in a manner similar to that of repositories by using coroutines or callbacks. You might, for instance, have a use case class in your application that integrates data from the courses and articles repositories that GeeksforGeeks uses.

Kotlin




class getCourseDataFromGfG(
  private val gfgCourses: Course Repository,
  private val gfgArticles: Article Repository,
  private val gfgAuthors: Author Names
  }


Use cases can be used by other use cases since they contain reusable logic. Multiple levels of use cases at the domain layer are typical. For instance, the use case illustrated in the following example can use the FormatDateUseCase use case if several UI layer classes depend on time zones to display the right message on the screen:

Kotlin




class getCoursesDataGromGfG(
  private val gfgCourses: Course Repository,
  private val gfgFormat:  Format The Content Here
  private val gfgAuthors: Author Names
)


This could be understood well by this diagram:

Understanding the Architecture of the Domain Layer

Image #2: Understanding the Architecture of the Domain Layer

Understanding the Cycle of the Domain Layer

Use cases are not given a separate lifespan. They are instead restricted to the class that makes use of them. As a result, use cases can be called from services, classes in the UI layer, or the Application class itself. Use case classes should be created as new instances each time they are passed as dependencies because use cases shouldn’t contain mutable data. It is necessary for use cases from the domain layer to be main-safe, or secure to call from the main thread. Use case classes are in charge of shifting any logic involved in lengthy blocking processes to the appropriate thread. Check to see if those blocking actions would be more appropriate in other layers of the hierarchy before proceeding, though. Complex calculations frequently take place in the data layer to promote caching or reuse. A resource-intensive action on a large list, for instance, is better suited for the data layer than the domain layer if the result needs to be cached for reuse across many app screens.

Upward Stream of Data is not possible

Image #3: Upward Stream of Data is not possible

Making this restriction has the advantage of preventing your user interface (UI) from ignoring domain layer logic, for instance, if you execute analytics logging for each access request to the data layer. The potentially serious drawback, though, is that you are compelled to create use cases, even if they are merely straightforward function calls to the data layer, which can add complexity for no gain.

Conclusion

The choice of whether to impose stringent guidelines or take a more flexible stance on access control for the data layer ultimately depends on your specific codebase. Hope this article helped you learn how to implement the domain layer in your application if you have the desire for an optimized code base.



Last Updated : 07 Feb, 2023
Like Article
Save Article
Previous
Next
Share your thoughts in the comments
Similar Reads