What is an efficient Flutter architecture pattern for personal development?

I've been working with Flutter for about two years and I'm currently searching for an architecture pattern that aligns well with my individual development needs. I'm particularly looking for a pattern that prioritizes the following:

Minimal code volume
Clear contracts and boundaries
Unidirectional data flow
Reusability
Testability
Maintainability

I've explored several architectures but haven't settled on any of them for the reasons I've mentioned below:

MVC: I found the role of the Model a bit unclear, which led me to rule it out.

Bloc: Despite recognizing Bloc's potential strength in a large team context, I observed that alternatives like Riverpod significantly reduce the volume of code, making Bloc less attractive for my individual development work.

Clean Architecture & DDD: I encountered too much boilerplate code which felt excessive for individual development. Thus, I decided against using this as well.

I am seeking recommendations on a suitable architecture pattern that would best fulfill my requirements. Thank you in advance for your suggestions and insights.

Solution

I'm still pretty certain that my strategy is working well for my recent developed apps:

view
- screens
- panes
- misc
app, mostly Riverpod stacks serving as:
- appstate (observable, mutable chunks of model data as state)
- services (holding ref and other state, returning object as state)
- singletons (holding ref, returning the object as state)
- repos (holding ref, returning the internal API object as state)
DTO layer (no state, just transforms between domain data and external)
external APIs
core (anything that's shared, like types)

It's based loosely on the layers I've seen in Reso Coder's DDD, mixed with what I know from heavily working with Riverpod. Nearly everything is inside a Riverpod wrapper, to serve as a service locator and to enable mocking-by-overrides during testing.

Code is re-used in the app layer through the use of family providers (if the providers are identical, but have distinct lifecycles), or the use of mixin classes (to give similar behavior to related Notifiers).