search

ResoCoder / flutter-tdd-clean-architecture-course

https://resocoder.com/flutter-clean-architecture-tdd/
2.01k stars 628 forks source link

Relations between features #23

Open sbitab opened 4 years ago

sbitab commented 4 years ago

Hi How can I use widgets or pages of another feature?

Example: For example, I have an authentication feature, I want to use the login widget of this plugin in the feature of my store, how should I do this?

If I import the widget into my storeframe, the modular structure will be lost, right?

ghezeli commented 4 years ago

hi i have same problem please help

dominikseger commented 4 years ago

I was asking me the same. If multiple features using the same widget, should it be in the core folder, because it's some kind of "global" then? There are so many cases where I need to use models,bloc pattern etc. across features that I don't know if this architecture is really gonna fit for me(or maybe I didn't understand it yet).

For example: I have a HomePage and SettingsPage, both of them would be a feature. On the HomePage there is a cog Icon which lead to the SettingsPage. If there is an update available, the cog icon on the HomePage should get a batch and in the SettingsPage there must be a button shown. I would need to share the the state(bloc logic) between them to archive this.

So should HomePage and SettingsPage should be one feature to share state or should this bloc be global under the core folder?

I appreciate your work @ResoDev, maby you finde the time to answer. Keep up the great work :)

mikeandersen commented 3 years ago

FWIW, in his newer DDD course, he recommends a different folder structure where features are nested under folders for each architectural layer, instead of the other way around. From Flutter Firebase & DDD Course:

I'm the first to admit that the folder structure outlined in the Clean Architecture course is a pain to deal with. With DDD, we're going to take a different approach.

Layers will hold features, not the other way around. This will still keep the code readable but, most importantly, it will ensure that adding more features and sub-features is going to be a pure bliss!

[...]

All in all, we can mix and match the dependencies in between features as long as we keep true to the dependency flow outlined in the diagram above (domain layer has to have ZERO dependencies on other layers).