On this article, I’ll clarify how we add a domain layer towards Now in the Android app to enhance readability, scalability, and portability.

Within the Android software structure, the area layer comprises the enterprise logic: the principles that dictate how the appliance works. In the remainder of this text, I will use the time period “logic” to imply “enterprise logic,” versus “consumer interface logic” or another type of logic.

It’s common to introduce the area layer as an software grows in complexity and use it to encapsulate complicated logic or logic that’s reused by many screen-level state holders, corresponding to ViewModels.

The pull request on which this text relies is here. I’ve simplified and renamed some lessons to deal with the fundamentals.

The area layer is created by shifting logic, usually from the consumer interface layer, to use instances. Use instances are capabilities (or lessons with a single public technique) that include logic. They carry out a single operation that usually combines or transforms knowledge from repositories or different use instances.

He naming convention for the use instances on this article (and within the Now in Android app) comply with the official guide of:

• current tense verb e.g Get
• noun/what e.g FollowableTopic
• UseCase suffix.

Instance: GetFollowableTopicUseCase

Right here is an summary of the method we use:

• Determine duplicate and complicated logic inside ViewModels
• Create use instances with applicable names
• Transfer logic inside use instances
• Refactor ViewModels to depend upon use instances as a substitute of repositories
• Add exams to be used instances

The next diagram reveals the information noticed by every ViewModel. Every field within the Observes column represents logic, which generally combines knowledge from a number of streams. Every field represents a candidate for a use case, and people with the identical shade point out duplicate logic.

The “UseCase” suffix is ​​omitted from the diagram for readability.

Now that the exhausting a part of “naming issues” is finished, we simply want to maneuver the logic from every ViewModel to its corresponding UseCase. Let’s check out an instance.

The logic for information articles is utilized in three completely different ViewModels.

Let’s check out this inside logic. BookmarksViewModel:

That is what is occurring:

1. Markers are obtained from UserDataRepository
2. Information assets (also referred to as articles) are sourced from NewsRepository
3. These two are mixed to create a listing of bookmarked information assets
4. The checklist is filtered to point out solely the marked information assets

The logic from steps 1-3 is widespread to all different ViewModels, so it may be moved to a brand new use case referred to as GetSaveableNewsResourcesUseCase. Right here is the code:

The use instances reside within the area layer, and to obviously separate this layer from the remainder of our code base we created a :area module. Lessons created by use instances, often on account of combining knowledge fashions from a couple of repository, had been additionally moved to the :area module.

A very good instance of that is the SaveableNewsResource knowledge class that’s the results of combining a NewsResource equipped from the NewsRepository forks isSaved property that’s calculated utilizing the checklist of bookmarks from the UserDataRepository.

Now we have now created GetSaveableNewsResourcesUseCase we are able to refactor BookmarksViewModel to name him

ViewModel is now easier, simpler to learn. It is clear to the constructor what this class is doing: get saveable information assets, and there is no want for a intermediary. bookmarks variable to retailer knowledge from the consumer knowledge repository.

There may be nonetheless some logic to filtering out unflagged information articles. We might have moved this filtering logic to a different use case (maybe referred to as GetSavedNewsResourcesUseCase) however creating a completely new class for a name to filter in all probability would not justify the elevated complexity of a further use case. Finally, it is as much as you to determine how a lot logic to translate into your use instances.

The opposite ViewModels can now be refactored to depend upon our use case. Including any widespread logic, corresponding to the power to return information assets for a given subject or writer, as we go.

We repeat this course of for every duplicate logic space:

• select a view mannequin
• transfer the logic to a use case
• refactor the opposite ViewModels to make use of the use case

After all we too added tests for every use case, and since use instances are easy capabilities, they’re very simple to check! Finally, by including a website layer, our code base is less complicated to take care of and scale.

You possibly can learn extra concerning the area layer in Now on Android on the Architecture Learning Journeyand extra detailed guidance on the official website for Android developers.