modulith/modulith-php

The CLI tool to work with ModulithPHP.

dev-main 2023-10-21 00:33 UTC

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

MIT

• Herberto Graca

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)

• 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]

• 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

• 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