Clean Architecture: Apps that rely heavily on background services

Question

I am trying to implement clean architecture (https://8thlight.com/blog/uncle-bob/2012/08/13/the-clean-architecture.html) on an Android app. As an example, let's say that all the app does is monitors a user's CPU temp and displays a hourly and daily average. Data is stored on the device and periodically downsampled. The downsampled data is uploaded to a backend.

All of the clean architecture examples I have seen is for the same types of apps - eg. Apps that have a UI to CRUD data, usually something in the line of: The UI sends click events to the presenter, presenter executes a use case interactor, interactor retrieves data from a repository, the presenter sends the data to the UI.

My app has practically zero user interaction:

• A background service measures the CPU temp and writes it to the
  database.
• A separate background process downsamples the data and writes it to the database.
• Yet another background process syncs the downsampled data with the backend
• The background services are scheduled to run on a fixed interval by a job scheduler
• All the user sees is his current CPU, the averages and maybe notifications that syncing has completed successfully.

How would I structure this in terms of clean architecture? More specifically:

• What are my use cases?
• Are the services in the same layer as the view would have been?
• Do I need a presenter at all? (Maybe for displaying status notifications from the service, I can't see any other reason?)
• Do I need separate repositories for my high resolution and lower resolution data?

I realise this is a lot of questions, but I would appreciate any input or pointers in the right direction.

Answer 1

The important part of Clean Architecture (CA) are not the presenters and controllers. The important point of CA is that there is "core" of your application, which represents your business cases. And that all of UI, infrastructure, service or databases depend on this core and not vice-versa. I recommend wathing Uncle Bob's talk to get clearer picture.

When I look at your code, youre "core" use case is a pipeline. This pipeline consists of multiple parts, each run separately with database in between them. But together, they do some processing. What I would like to see is automated test that tests the whole pipeline as singular unit. The database and scheduler would be mocked out and the pipeline would not know if it is running in production or if it is being tested with in-memory database and run directly and not through scheduler.

Answer 2

The MVC paradigm is a guideline for structuring your program in a proper and easily interpreted way. As you mention yourself, there is very little interaction and view with the user, so should you create classes and layers which ultimately perform a trivial purpose? You could of course, but it is no longer proper and easily interpreted. Programmers reading your project would be dumbfounded by the existence of view classes which do little more than grab the average, round it to 2 decimal places, and show it to the screen. It helps to remember that it is only a guideline, not a rulebook of coding.

To answer your specific questions:

What are my use cases?

Here you go:

User wants to know average CPU usage. User enters the program and notes the percentage labeled clearly. User closes the program.

User wants to know time program last synchronized. User enters the program and notes the date labeled clearly. User closes the program.

It is as simple as you probably have guessed already. Don't overanalyze.

Are the services in the same layer as the view would have been?

Honestly, I would separate the background tasks with the user UI, but mostly this is because the tasks being performed are clearly different. So no.

Do I need a presenter at all? (Maybe for displaying status notifications from the service, I can't see any other reason?)

I could see maybe the need for one class that focuses purely on funneling the data into data for the user to see. I think calling it a presenter is glorifying the role a bit.

Do I need separate repositories for my high resolution and lower resolution data?

I wouldn't. If anything you may consider having a second table.