https://kotlinlang.org logo
l

Lilly

11/10/2020, 5:53 PM
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
.
k

KamilH

11/10/2020, 6:15 PM
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
j

Javier

11/10/2020, 6:48 PM
BluetoothDatasource
👍 1
l

Lilly

11/11/2020, 2:20 PM
@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
?
j

Javier

11/11/2020, 2:24 PM
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
l

Lilly

11/11/2020, 4:05 PM
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 :)
j

Javier

11/11/2020, 4:28 PM
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
l

Lilly

11/11/2020, 5:03 PM
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.
j

Javier

11/11/2020, 5:55 PM
You can't apply clean if you don't have usecases
CleanArchitecture (1).jpg
2 Views