-
Notifications
You must be signed in to change notification settings - Fork 495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
You don't seem to understand Clean Architecture #72
Comments
CleanCodeRxSwift would be a better name for this repo. You write clean code I give you that! But calling this clean architecture is a misnomer and would only confuse people. |
I agree, the reason why domain in this example is “empty” module with no implementation, is because I wanted to implement 3 different concrete implement of the same domain and put them into separate module. In real app I would definitely not do that, I’d have domain which hides implementation detains behind adstraction, what I mean that all concrete usecases would be there and accessed via Service locator or any other DI pattern.
The reason I called it Clean Arch is because it’s literally implementation of what Uncle Bob was talking about here https://youtu.be/Nsjsiz2A9mg and it uses RxSwift 🤷♂️ |
I don’t agree here, unless I’m missing something, all concrete use cases are internal and sit in separate modules, the only way to create them are via corresponding use cases providers |
I see that efforts have been put to implement Uncle Bob's Clean arch, but I agree with @mycroftcanner that this is not clean architecture. In clean arch we have domain that has implementations of uses cases along with interfaces of use cases. |
I’m struggle to understand how in this case the Domain is dependent on anything? It sits in separate module and does not know anything about the implementation of a DB |
@mycroftcanner Not to take away from the great work done in this repo but could you point me toward an example of what 'you' think repository pattern in clean architecture should look like? |
Your domain has entities... but they have absolutely no logic or critical business rules associated to them... it only defines entities and a use case provider protocol...
You have 3 redundant use cases provider implementations that are fully aware of everything and can't talk to each other.
Use cases implementation should have no knowledge about core data, realm, etc... you just write platform agnostic code... using protocols and inject adapters as dependencies.
The text was updated successfully, but these errors were encountered: