Overall concept
The code is organised in accordance with the Clean Architecture approach. The business logic is separated from the presentation logic.
Transactions functionality has its separate Flutter package, located at SaFiMono/app/features/transactions.
This package contains mostly UI and business logic. The compositional architectural pattern was chosen to be BLoC.
BLoC for each screen is getting injected the use case entities that it need to perform its business logic. Use cases are also a part of feature.
Usecases, in their turn, contain the references to the repositories, softly. There is a library/data_abstraction package, that contains all the declarations of data objects and repositories.
Data objects are of 2 types:
1. DTO, containing the description of the entity (all the fields, initialisers, implementation of Equatable, etc.)
2. Models, which contain parsing from/to JSON logic.
Repositories themselves are pure interfaces, so they are only a declaration of methods used to interact with data objects. The implementation for repositories resides inside the feature/mobile_data package.
Along with the implementation, this package contains also Tables, used to store data in Hive.
This architecture allows us to maintain the separation of concerns based on the responsibility of different classes.
Transactions feature specifics
Flutter code in Transactions feature can be found in 2 major folders:
lib/ contains all the production code, related to Transactions
test/ contains all the unit- and ui-tests for Transactions; the inner structure of this folder should replicate one in lib/
Let’s examine the structure of the lib folder contents within transactions package.
It contains 3 folders:
common – contains logic common for all the classes in the package: Injector, Logger, and common UI widgets;
domain – contains navigation and use cases;
presentation – contains BLoCs for the screens, distinguished by journey; journey corresponds to the actual UX flow.
Let’s dive into the presentation layer.
It contains the BLoCs separated by their intention. Here is a list of their categorisation:
bank_statement – responsible for downloading and displaying bank statements list and details;
buy_load – responsible for the Buy load flow from Shortcuts or Payments landing page;
common – contains the screens that are reused across different journeys (i.e. transaction results, transaction details);
pay_bill – responsible for paying bills functionality, launched from Shortcuts or Payments landing page
send_money – responsible for sending money from Shortcuts or Payments landing page: Intrabank (SaFi), Interbank, E-Wallet, OTC Cash-out;
top_up – responsible for all the cash-ins from Shortcuts or Payments landing page (from the bank account, e-wallet, debit card, or over-the-counter);
transaction_filters – contains screens for filtering the transactions in the transactions list;
transactions_history – responsible for displaying the transactions history and navigating/searching/filtering though it;
transactions_list – common widget for Payments and Transactions history screens.
