modulith / modulith-php
The CLI tool to work with ModulithPHP.
Installs: 0
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Forks: 0
pkg:composer/modulith/modulith-php
Requires
- php: ^8.2
- hgraca/php-extension: ^v2.3.0
- modulith/arch-check: ^0.1.0
- symfony/config: ^v6.3.2
- symfony/console: ^v6.3.4
- symfony/dependency-injection: ^v6.3.5
- twig/twig: ^v3.7.1
Requires (Dev)
- ergebnis/composer-normalize: ^2.39.0
- friendsofphp/php-cs-fixer: ^v3.35.1
- malukenho/mcbumpface: ^1.2.0
- overtrue/phplint: ^9.0.4
- phpstan/phpstan: ^1.10.38
- phpstan/phpstan-beberlei-assert: ^1.1.2
- phpstan/phpstan-deprecation-rules: ^1.1.4
- phpstan/phpstan-phpunit: ^1.3.15
- phpstan/phpstan-strict-rules: ^1.5.1
- phpunit/phpunit: ^10.4.1
- psalm/plugin-phpunit: ^0.18.4
- rector/rector: ^0.18.5
- roave/security-advisories: dev-master
- vimeo/psalm: ^5.15.0
README
This is the repository of the CLI tool to work with ModulithPHP.
Goals
- Enforce higher level architecture- Layers- Dependencies must go inwards & downwards
- Core must not implement or extend from ports (allow for exceptions like commands and events)
- Classes must only have sensible dependencies
 
- Slices- Adapters must be decoupled
- Core components must be decoupled
- Core components tests must be decoupled
 
- Code style- Classes must be suffixed
- Classes must not be suffixed
 
- Quality- Exceptions must inherit from project exception tree
- Classes must not rely on reflection (there are exceptions like compiler passes)
- Classes must be in map (ie a serialization map, so we are sure they can go ito a message queue)
 
 
- Layers
- Generate schematics for the project- C4 model (only 3 levels)- System Context diagram: Provides a starting point, showing how the software system in scope fits into the world around it.
- Container diagram: Zooms into the software system in scope, showing the high-level technical building blocks.
- Component diagram: Zooms into an individual container, showing the components inside it.
 
- Application map [1] [2]
 
- C4 model (only 3 levels)
- Architecture forensics metrics- Hotspots detection (complexity * change_rate)- Prioritize code for refactoring
 
- Code units temporal coupling- If there is no reason for them to change together (unlike tests and the code they test), they should probably be refactored
 
- Code units ownership analysis- To detect team knowledge deficiencies
 
- And plenty more...- Try to reuse phpmetrics
 
 
- Hotspots detection (complexity * change_rate)
- Split a project per component- Analyse the monolithic project dependencies and create split versions per component so that they can be deployed independently as microservices