Service in clean architecture

Question

Where does Service (or BroadcastReceiver, etc..) belongs to in clean architecture package structure? I am wondering between domain and data layer... I would create new package called services in domain package. Is that right, or I should do it other way?

Answer 1

When thinking about clean architecture You should think of an Android Service in similar way as on any other Android application component like Activity for example.

Service and Activity can both do similar things like playing music, performing network requests etc. with one difference being the lack of user-interface in case of a Service (although one could think of a Notification as an UI for a Service). This lack of UI might be misleading at first.

Having in mind similar purposes of those application components we can imagine that both Service and Activity can be located in the same layer of the clean architecture project.

First I wouldn't choose the data layer as it is a place for Your data sources (concrete implementations of the abstractions defined in the domain layer) like web APIs or database controllers. One would argue that a Service is somewhat of a data source for the application because You can bind to it and get data from the background but if You look at Activities or Fragments You will notice that they can also be data sources for other Activities by using the Intents or arguments.

I wouldn't choose the domain package as well - it is supposed to contain definitions of the business logic of the app - interfaces of repositories etc. Moreover, this layer should be platform-independent, so no Android components should be there. A Service definitely does not belong there.

The app (or presentation) layer is left. It is an Android-specific layer - and this is the place for a Service. Service can communicate directly with a neighbour domain layer to access the data via use-cases that it can pass to a bound Activity, display a Notification with the data or whatever. All that while not violating the clean architecture rules.

Answer 2

Let's refer to the primary source, the book "Clean Architecture: A Craftsman's Guide to Software Structure and Design".

First establish, how many layers are in the clean architecture.

The architect can employ the Single Responsibility Principle and the Common Closure Principle to separate those things that change for different reasons, and to collect those things that change for the same reasons—given the context of the intent of the system.

What changes for different reasons?

User interfaces change for reasons that have nothing to do with business rules. Business rules themselves may be closely tied to the application, or they may be more general. The database, the query language, and even the schema are technical details that have nothing to do with the business rules or the UI.

Thus we find the system divided into decoupled at least four horizontal layers — the Application-independent business rules, Application-specific business rules, UI, and the Database.

Later Uncle Bob describes the implementation of The Clean Architecture with the corresponding four layers, giving them explicit names:

1. Enterprise Business Rules (Entities);
2. Application Business Rules (Use Cases);
3. Interface Adapters;
4. Frameworks & Drivers;

Now let's take a look at "BroadcastReceiver" for example, what is this? A BroadcastReceiver is an Android component that allows you to register for system or application events and respond to them.

I guess it is obvious that the first two layers (business rules) have nothing to do with the Android framework, since they are written in a pure programming language, with no idea about where that code will be executed. The idea, behind that decoupling, is in reusability, that you can use these first two components (packages) for running on any other device, not necessarily on Android.

Now we are left with two layers, "Interface Adapters" and "Frameworks & Drivers"

What Uncle Bob says about these two layers.

The software in the interface adapters layer is a set of adapters that convert data from the format most convenient for the use cases and entities to the format most convenient for some external agencies such as the database or the web. The presenters, views, and controllers all belong in the interface adapters layer. No code inward of this circle should know anything at all about the database.

The frameworks and drivers layer is where all the details go. The web is a detail. The database is a detail. We keep these things on the outside where they can do little harm. Between the use case interactors and the database are the database gateways. These gateways are polymorphic interfaces that contain methods for every create, read, update, or delete operation that can be performed by the application on the database.

Now depending on what is your "Service" is closer to the description above, you can place to the corresponding layer.

In my humble opinion, since, for example, "BroadcastReceiver" is a pure, framework tool, which cannot be used outside of the Android device, it will go to the "Frameworks & Drivers" layer.

But that is by the book.

In practice, we have to adjust the guidelines provided by the book for our requirements. So it depends on how you use that "service" and the type of the service.

Since in Android, UI (Interface Adapters) still have a dependency on the Android framework, and for example, "foreground services" have some UI, you can think of that service as a "Controller", in that case, it must be in the "Interface Adapters" layer.