Motivation

Code organisation and ownership

• Logically-connected features are placed in one module, instead of being distributed across the application.
• In this approach, the Data Layer, Business Models, DI and Tests are distributed across specific modules, unlike the feature-based architecture where they are grouped together (services, repositories)
• Improved PR review process due to code encapsulation through modules.
• Possible widgetbook integration

Efficient work distribution for squad-based projects

• One squad owns one or multiple modules.
• All squads own the following packages
  • shared package
  • the application itself.
  • Design system and assets

Disadvantages

Not-suitable for small applications (Less than 4 Flutter Engineers, less than four months)

High complexity and extra development overhead compared with the feature-based structure

• Dealing with separate packages (shared, design_system and assets)
• Feature-agnostic routes and route resolver
  • An extra route model class needs to be implemented in the shared package
  • Each route model must be mapped to a go_router route in the route resolver service.
• Direct dependencies needs to be specified in every module.
  • Note: the required dependency versions need to be specified only in the end modules

Limitations

• Module-specific objects can’t be passed through the Coordinator class
  • Record types or shared models should can be utilized.
• Localisations and Permissions must be implemented in the shared package.
• Integration tests must implemented in the application.
• Domain-specific error codes must be implemented in the shared package.