Clean Architecture (feature-based)

[dariowskii]

🎯 Description

This PR introduce the new project structure.

This pull request introduces two significant changes: a shift to a Clean Architecture pattern for organizing the project structure and the adoption of relative imports for better modularity and maintainability. The updates improve the codebase's organization by separating concerns into distinct layers and consolidating shared resources into a shared directory.

Clean Architecture Adoption:

• Updated the coding style documentation to describe the new feature-based folder structure, which separates the codebase into Data, Domain, and Presentation layers. This structure replaces the previous widget-based organization. [1] [2]

Relative Imports and Folder Restructuring:

• Replaced absolute imports with relative imports across multiple files to align with the new shared directory structure, consolidating models, providers, utilities, and widgets into a shared module. [1] [2] [3]
• Renamed and relocated feature-specific files (e.g., account_page.dart, add_category.dart) into a features directory, adhering to the feature-based organization. [1] [2] [3]
• Removed redundant or unused code, such as the duplicatedTransactoinProvider listener in account_page.dart.

Closes: #411

📱 Changes

• [x] Describe key changes made
• [x] List any new features, bug fixes, or refactors
• [x] Include additional details if necessary

🔍 Checklist for reviewers

• [x] Code is formatted correctly
• [x] Tests are passing
• Tested on:
  • [x] iOS
  • [x] Android

[fres-sudo]

Thanks for the PR. Reviewing the features/ directory, I'm finding the organization unclear.

Some subfolders seem to represent pages (graphs_page, settings_page, transactions_page, dashboard_page) rather than application features. I would consider core functionalities like transactions, accounts, notifications, and planning to be the actual features.

Folders like backup_page and add_page (and many others) also appear to be pages, not features. The mix of xxx_page and xxx_feature suffixes in the naming is also confusing.

This page-based structure within features/ doesn't quite align with a typical feature-driven architecture. We should either clearly define what we mean by "feature" and refactor accordingly, or perhaps adopt a different structure (like technical folders) if a feature-based approach isn't the goal here.

What are your thoughts?