Isolation of modules
Within the framework of the methodology, all modules are distributed by scopes of responsibility (layer, slice, segment)
The layers, in turn, are organized vertically:
- "At the bottom" are the reused modules (ui-kit, internal libraries of the project), as the most abstract
- And as you move "up", more specific modules are located.
Regardless of whether it belongs to any slice, each module is required to provide a public access interface.
The interaction of each module with the rest of the application is designed taking into account a number of requirements:
Low coupling with other modules
- A change in one module should have a weak and predictable effect on others
High cohesion - the responsibilities of each module are "focused" on one task
- If the module has too many responsibilities (starts "doing too much") - this should be noticed as soon as possible
Absence of cyclic dependencies on the scale of the entire application
- Often lead to unexpected, undesirable behavior, it is better to avoid them altogether
To meet these requirements, within the framework of the methodology, it is necessary to observe the basic rule:
A module can depend only on "underlying" modules, but not on modules from the same or higher layer
features/authcannot depend on
features/filtersand vice versa
features/authmay depend on
shared/ui/button, but not vice versa
Following this rule allows you to keep dependencies "unidirectional" - which automatically eliminates cyclic imports and significantly simplifies tracking dependencies between modules in the application.
Violation of this rule is a signal of problems:
The module has import from another module from its own layer
- Perhaps the module was unnecessarily fragmented or has unnecessary responsibility.
- You should combine it with the imported module or move it (partially or completely) to the layer below or transfer the logic of relationships to modules on higher layers.
The module is imported by many modules from its own layer
- Perhaps the module has extra responsibility.
- You should move it (partially or entirely) to the layer below, or transfer the logic of connections to modules on higher layers.
The module has imports from many modules from its own layer
- Perhaps the module belongs to another scope of responsibility.
- You should move it (partially or completely) to the layer above.