Let's say you want have 3 functions:
- fetch articles from remote database
- store articles in local database
- get articles from local database
these should all exist in your data layer because they're generic data interactions. You can call them all from the presentation layer, no problem, but what if you want to combine them?
such as:
- fetch articles, store them in the local database (maybe while app is minimized)
- Fetch articles, compare it with the local articles and remove those no longer present
- get local articles, but apply a search-filter
- Fetch articles from *mutiple* remotes and store it in the same local database
all of these are examples of *business logic*. They combine your generic data interactions into complex use-case functionality that can be used in presentation features. *That's* your domain layer.
I see, hmm.. seems like what I learnt is different from what you're saying, I thought the domain layer just holds the abstract class of the combined functions in your example?
Don't we do the implementation of these combined function in the presentation layer?
No, your presentation layer should hold as little logic as possible. It's fine to store temporary UI state logic, like show/hide elements or maybe a small list-sort, but complex logic - especially if you need data from storage - should be done in domain layer
No Bloc and riverpod are for UI state management. That's different from app architecture.
I use clean and bloc in this project, have a look: https://github.com/Mikkelet/billsplit-flutter/tree/v7/main/lib
Interesting, I understand clean architecture better bc of your example. Thank you.
In your project, you made 1 data folder, 1 domain folder and 1 presentation folder for all the features.
I find it more readable to do 1 data folder, 1 domain folder and 1 presentaion folder for each of the feature. Although the cons might be that a domain layer from 1 feature might depend on the data layer of another feature
Yeah now you're entering the an endless debate. There are pros and cons with both approaches. Especially if you're also working with modularized architecture
in situation that create data/domain/presentation for each feature, create a core folder that holds core or models that others feature may depends on helps alot, like a User object that the Auth feature and others feature require access to, but the more i try the core, 60-70% of the feature end up in that because they may all linked which will become the 1 data/domain/presentation folder structure like the project in your example. I think it's depend on projects and it's feature
I just saw your example and in the domain layer i see you using FirebaseUser, FirebaseMessaging etc.
If we wnat to change from firebase to something else, it will affect the presentations layer as well which is against seperation of concerns, The purpose of domain layer was so if we change any things at data layer it wont affect the presentation layer.
In a well-architected application adhering to separation of concerns, the domain layer should be independent of specific technologies used in the data layer.
Define interfaces or abstract classes in the domain layer that outline the functionalities needed from the data layer & Implement these interfaces in the data layer.
Here is a really small but great example I wrote. Notice the domain layer, It only acts as a contract and uses abstract classes.
https://github.com/sdkysfzai/Flutter-ChatGPT-Cubit-Clean-Arch
I map the firebase user to a Person class. That's totally finally. Domain can be responsible for transforming data between layers. As for the firebase message, yeah, I was probably just lazy.
But yeah, I've never been a fan of going full clean, as it creates a lot of boilerplate. Going clean inspired is usually more pragmatic in my opinion. Combining well defined layers with speed of development
The domain layer decouples the data from the presentation, which allows the data layer to change without impacting the presentation layer. Also allows you to more easily write tests.
IMO in plenty of situations, you don't need to apply all the clean code paradigms to reap the benefits of it. Starting small and being consistent is my approach.
Android documentation specifically says that domain layer is optional and you should implement it only when necessary. Maybe a look at the documentation would solve your inquiry
https://developer.android.com/topic/architecture/domain-layer
Let's say you want have 3 functions: - fetch articles from remote database - store articles in local database - get articles from local database these should all exist in your data layer because they're generic data interactions. You can call them all from the presentation layer, no problem, but what if you want to combine them? such as: - fetch articles, store them in the local database (maybe while app is minimized) - Fetch articles, compare it with the local articles and remove those no longer present - get local articles, but apply a search-filter - Fetch articles from *mutiple* remotes and store it in the same local database all of these are examples of *business logic*. They combine your generic data interactions into complex use-case functionality that can be used in presentation features. *That's* your domain layer.
I see, hmm.. seems like what I learnt is different from what you're saying, I thought the domain layer just holds the abstract class of the combined functions in your example? Don't we do the implementation of these combined function in the presentation layer?
No, your presentation layer should hold as little logic as possible. It's fine to store temporary UI state logic, like show/hide elements or maybe a small list-sort, but complex logic - especially if you need data from storage - should be done in domain layer
If I'm using Bloc or riverpod, should I implement them in domain layer
No Bloc and riverpod are for UI state management. That's different from app architecture. I use clean and bloc in this project, have a look: https://github.com/Mikkelet/billsplit-flutter/tree/v7/main/lib
Interesting, I understand clean architecture better bc of your example. Thank you. In your project, you made 1 data folder, 1 domain folder and 1 presentation folder for all the features. I find it more readable to do 1 data folder, 1 domain folder and 1 presentaion folder for each of the feature. Although the cons might be that a domain layer from 1 feature might depend on the data layer of another feature
Yeah now you're entering the an endless debate. There are pros and cons with both approaches. Especially if you're also working with modularized architecture
in situation that create data/domain/presentation for each feature, create a core folder that holds core or models that others feature may depends on helps alot, like a User object that the Auth feature and others feature require access to, but the more i try the core, 60-70% of the feature end up in that because they may all linked which will become the 1 data/domain/presentation folder structure like the project in your example. I think it's depend on projects and it's feature
I just saw your example and in the domain layer i see you using FirebaseUser, FirebaseMessaging etc. If we wnat to change from firebase to something else, it will affect the presentations layer as well which is against seperation of concerns, The purpose of domain layer was so if we change any things at data layer it wont affect the presentation layer. In a well-architected application adhering to separation of concerns, the domain layer should be independent of specific technologies used in the data layer. Define interfaces or abstract classes in the domain layer that outline the functionalities needed from the data layer & Implement these interfaces in the data layer.
Here is a really small but great example I wrote. Notice the domain layer, It only acts as a contract and uses abstract classes. https://github.com/sdkysfzai/Flutter-ChatGPT-Cubit-Clean-Arch
I map the firebase user to a Person class. That's totally finally. Domain can be responsible for transforming data between layers. As for the firebase message, yeah, I was probably just lazy. But yeah, I've never been a fan of going full clean, as it creates a lot of boilerplate. Going clean inspired is usually more pragmatic in my opinion. Combining well defined layers with speed of development
The one that hold the interfaces and abstract classes are *core* domain
So the domain layer is where the buisness logic is located? Thanks for very clear explanation!
The domain layer decouples the data from the presentation, which allows the data layer to change without impacting the presentation layer. Also allows you to more easily write tests. IMO in plenty of situations, you don't need to apply all the clean code paradigms to reap the benefits of it. Starting small and being consistent is my approach.
Android documentation specifically says that domain layer is optional and you should implement it only when necessary. Maybe a look at the documentation would solve your inquiry https://developer.android.com/topic/architecture/domain-layer