Archer is a lightweight framework for FCA (Functional Clean Architecture). It’s based on Arrow as a foundation and provides all the necessary elements.
dependencies {
implementation("com.m2f-kt:archer-core:{version}")
}Normally when we talk about clean architecture we can state its benefits:
- Abstraction
- Reusability
- Scalability
But it comes with serious tradeoffs:
- Boilerplate
- Maintainability
graph LR
UC["UC"]
Repo["Repo"]
DSL(("DSL"))
DSR(("DSR"))
MRTD{{"Map to Domain"}}
MDTD{{"Map to DBO"}}
MDBTD{{"Map Domain"}}
UC -->|"1: Req data"| Repo
Repo -->|"2: Fetch remote"| DSR
DSR -->|"3: Return data"| MRTD
MRTD -->|"3a: Map to Domain"| Repo
Repo -->|"4: Store local"| MDTD
MDTD -->|"4a: Map to DBO"| DSL
DSL -->|"5: Return data"| MDBTD
MDBTD -->|"5a: Map to Domain"| Repo
Repo -->|"6: Return data"| UC
classDef mapping fill:#b44,stroke:#333,stroke-width:2px;
class MRTD,MDTD,MDBTD mapping;
DSL -> DataSource Local
DSR -> DataSource Remote
UC -> UseCase
To implement this diagram we would need normally an interface and implementation for each of the actors in the diagram, this is:
- Usecase interface + Implementation (Optional)
- Repository interface + Implementation
- N * (DataSources + Implementation) where N is the number of different datasources the repository would orchestrate. ( on average 2)
- X + Y Mappers Where X is the number of models different than the domain and Y is the number of data sources that expects and input model (database for example)
If we follow the previous example diagram we may need:
- 2 Usecase elements
- 2 Repository Elements
- 4 DataSource Elements (network and local)
- 3 Mappers (network -> domain), (local -> domain), (domain -> local)
This structure can be tedious to implement and the more use cases you need, the harder to maintain it comes. Archer provides contractual data sources and Repositories for you to avoid the need to create all the boilerplate ( except the mapping, sorry, mappings are needed :D).
With archer that same structure could be implemented the following way:
// This DSL creates a GetDataSource, a computation that accepts an Int and returns a String
val remoteDataSource = getDataSource<Int, String> { param: Int -> “${ param }” }
// This is a default storage but devs can implement their own one.
// A Store dataSource has 2 tipe of queries, Get<Int> and Put<Int, String>, and the developer
// can implement both in order to provide a storage mechanism
val store: StoreDataSource<Int, String> = InMemoryDataSource()
val repositoryStrategy = remoteDataSource cacheWith store expiresIn 5.minutes
// ice stands for Idle | Content | Error
val resultIce = ice {
repository.get(StoreSync, 0)
}
// Arrow's Either
val resultEither = either {
repository.get(StoreSync, 0)
}
val resultNullable = nullable {
repository.get(StoreSync, 0)
}
val resultFailingIce = ice {
raise(DataNotFound)
}
result shouldBe Ice.Content("0")
resultEither shouldBe Right("0")
resultNullable shouldBe "0"
resultFailingIce shouldBe Ice.Error(DataNotFound) // with either and nullable DSLs it would be Either.Left(DataNotFount) and null respectively