Build app structure using Riverpod

[trunghvbk]

Documents

• Read this article to understand about Riverpod: https://codewithandrea.com/articles/flutter-state-management-riverpod/
• App Architecture: https://codewithandrea.com/articles/flutter-app-architecture-riverpod-introduction/
• Read this article to build Repository Pattern: https://codewithandrea.com/articles/flutter-repository-pattern/

[trunghvbk]

Plus note: This basic project must be able to write Unit test.

[trunghvbk]

Reading this article of Andrea brought to me a clearly sight when struture an App.
https://codewithandrea.com/articles/flutter-project-structure/

• We should try feature-first instead of layer-first approach
• Features are not only screens, features should be the tasks, the functions of the users that we add into our app.
• Apply domain-driven design from the start

Noting the conclusion:

[How to do feature-first, the right way](https://codewithandrea.com/articles/flutter-project-structure/#how-to-do-feature-first-the-right-way)
In summary, the feature-first approach lets us structure our project around the functional requirements of our app.

So here's how to use this correctly in your own apps:

start from the domain layer and identify the model classes and business logic for manipulating them
create a folder for each model (or group of models) that belong together
within that folder, create the presentation, application, domain, data sub-folders as needed
inside each sub-folder, add all the files you need
When building Flutter apps, it's very common to have a ratio of 5:1 (or more) between UI code and business logic. If your presentation folder ends up with many files, don't be afraid to group them into sub-folders that represent smaller "sub-features".

For reference, here's how my final project structure ended up:

‣ lib
  ‣ src
    ‣ common_widgets
    ‣ constants
    ‣ exceptions
    ‣ features
      ‣ address
      ‣ authentication
      ‣ cart
      ‣ checkout
      ‣ orders
      ‣ products
      ‣ reviews
    ‣ localization
    ‣ routing
    ‣ utils
Without even looking inside folders such as common_widgets, constants, exceptions, localization, routing, and utils, we can guess that they all contain code that is truly shared across features, or needs to be centralized for a good reason (such as localization and routing).

And these folders all contain relatively little code.

[trunghvbk]

In fact, separation of concerns is the #1 reason why we need a good app architecture.

[trunghvbk]

Separation of concerns should be a primary concern when building apps. Using a layered architecture lets you decide what each layer should and should not do, and establish clear boundaries between various components.

[trunghvbk]

Remember to provide unit tests along the journey
if missing some of them, please make updates in the near future.