Hey guys, I have a theoretical question. I'd like to follow Clean Architecture, having a presentation/domain/data layer and representing my business logic as use cases within the domain layer which act as mediator between my view model and

my class

that provides the data. So far so good. Usually

my class

would be a

repository

but in my case the only data source of truth is a bluetooth device. I will definitely need a sort of abstraction between my bluetooth device and the use cases. So my question: How would you name this abstraction? Is it a

Repository

,

Facade

,

Proxy

,

Gateway

,

Bridge

,

Wrapper

,

Mediator

.

Maybe simply

Source

? It’s a common case to call your data sources like

NetworkSource

,

DatabaseSource

,

FileSource

etc. Then if you need to apply some logic to your sources you can group them into

Repository

@Javier @KamilH Thanks for your input. What responsibility does a

DataSource

object have? To be honest...when I would make it right, I would avoid a repository completely and put my abstraction logic into the appropriate

UseCase

class. The abstraction I want to extract is just extended business logic. But the extraction to an extra layer (repository) allows the domain layer (I'm using a 3-tier module architecture) and so my use cases to be a pure kotlin library module without android framework dependencies. When I put the extended logic into an use case, I will have to depend on android framework. What do you think guys, what would you recommend? Would you still call it

BluetoothDataSource

?

I use the

DataSource

abstraction to transform models to domain, so later in the

Repository

and/or

UseCase

all datasources are using the same domain models, but I think it is not an universal rule.

So you encourage me to go with pure kotlin library module and extract my abstraction to the data layer right? Just for clarification that I understand you right :)

Yeah, I think all domain implementations should go to your data layer keeping the domain layer only with interfaces and/or models

Does shifting all domain implementation to the data layer mean that I have no

UseCase

classes? According to the most common blog posts about Clean Architecture in Android the use cases are part of the domain layer and they represent the business logic and same layer defines a repository interfaface which the data layer has to implement.

You can't apply clean if you don't have usecases