How to decouple a large Flutter app into independent packages?

I’m writing this as an answer because it’d be too clumsy as comments.

From an SO perspective you’ve got 4-5 questions here, you might want to explore them individually 🙂

I know nothing about Flutter and Dart specifically, but it sounds like there’s lots of technology agnostic architecture and system design ideas that could be applied to improve the objective nature of the code base. It’s hard to provide specifics given the high-level nature of your question.

Some general things to consider:

• Is the code arranged into logical layers? At the very least keeping UI / presentation code separate from "business logic" from data-access code? If not, that’s a good basic starting point.
• Are you familiar with any architectural styles, such as Clean Architecture (just one example of several)? If not, take a look. Clean talks about separation of concerns that will help you with problems like how to share the database.
• Are you familiar with SOLID?

Packages & State

Global state (BLoC): How do you handle shared state across packages
using BLoC, or should each package manage its own state?

Just in case you are not familiar with layers & layering in an application, generally speaking things within a layer can talk to one another. I’m not sure if in your case a package is a logical group (i.e. cohesive group) of classes within one layer – or more like a Vertical Slice (cuts across several layers).

If for you, package == vertical slice, then I think typically each package would deal only with it’s own state. Be aware that sometimes concepts are shared between slices/packages – say at the database level, and therefore there might not be a simple clean way of saying something is in one package or another. All I can say is to be pragmatic and apply the KISS principle if you are in doubt.

Prototype First

One piece of advice, if you are applying new ideas to a large code-base, consider prototyping them out first, so that you can better ensure that:

• You understand the idea you are applying (is it actually the right approach).
• You understand how to apply it correctly.
• You understand the implications of what you are doing, especially the unexpected ones. Not just the affect on the code base as a static thing, but also in terms of deployment, runtime, performance, etc.

Keep in mind that sometimes you might be able to prototype an idea in a small test-harness, but other times you might want to take a snapshot of the entire code base and trial the change. I.e. a "throwaway" version of the code. I usually find that the first time I do something is not the best.