|
3 | 3 | # Why and What is the aim? |
4 | 4 |
|
5 | 5 | This project aims to demonstrate a feature-based modularization by managing the inter-feature dependencies through a dedicated navigation module and draws inspiration from Hexagonal Architecture and Clean Architecture to isolate the core of the application (domain logic or business logic) from other factors, allowing for a more flexible and decoupled system design. |
6 | | - |
| 6 | + |
7 | 7 |
|
8 | 8 | # Architecture Opinion |
9 | 9 |
|
@@ -40,7 +40,7 @@ With this opinion, the domain layer has a sole dependency on domain-impl. Withi |
40 | 40 | This module orchestrates the screen transitions and manages the navigation routes within the app. The Navigator class is equipped with functions that facilitate navigation to different screens, while AppNavigation is responsible for setting up the navigation routes. Crucially, the Navigation module operates independently of other modules, which plays a key role in decoupling feature modules from one another. This means that individual features do not have direct knowledge of each other, and all inter-feature navigation is coordinated through the Navigation module. |
41 | 41 |
|
42 | 42 | ### Navigation Flow: |
43 | | - |
| 43 | + |
44 | 44 |
|
45 | 45 | ### Advantages: |
46 | 46 |
|
@@ -78,7 +78,7 @@ The Network Module is a critical component of the architecture, encompassing all |
78 | 78 |
|
79 | 79 | ### Dependencies Flow |
80 | 80 |
|
81 | | - |
| 81 | + |
82 | 82 |
|
83 | 83 | ### App Screens: |
84 | 84 |
|
|
0 commit comments