A modern programming language that makes developers happier.

kotlinlang

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`

<@UE206C71V> <@URJ0QJJRM> 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.

All domain logic should avoid being coupled to the framework, so the UseCase interface should be, even, Kotlin common code

if you need multiple implementations to get this usecase working in multiple platforms or just one, is irrelevant

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

or classes that only depend of domain logic

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