We plan to extend this tutorial with three more topics: testing, navigation between screens within a feature, and navigation between features. If you have a non-primitive state that you want to pass between screens, then most likely these screens are part of the same feature. To pass such data, we introduced a feature state. All screens in the feature have access to this state and may update it. Navigation within the feature also relies on the feature state. I hope to cover this in more detail later, but to give you some direction now — look at https://pub.dev/packages/flow_builder. In terms of this package, "Flow State" is the feature state, and "FlowBuilder" is the entry point into the feature. It makes sense to keep features small still.

If we are talking about completely separate features that require the same data, that means the data is part of your domain. My recommendation would be to put that data into the domain layer, create some sort of repository for it, and pass a primitive identifier between features instead of actual models.

Domain modeling is hard, but the more time you spend on it, the more obvious the boundaries between features will be, and the simpler it will be to maintain the app later on.

As a rule of thumb, I'd recommend making everything private and extracting models to shared/utility code only when needed.