Download the PHP package kodzila/architecture-validator without Composer

Architecture validator

Motivation

Most projects are monoliths with some rules maintained to allow projects to scale if needed. Those rules must normally be enforced during code review and are exhausting to check each time.

This library aims to specify those rules explicitly by having a tool to check the rules automatically.

Inspiration was taken from Java ArchUnit and not maintained anymore PhpArch.

Installation

Via composer:

Running

Library itself does not provide any runner - it is only set of functionalities to validate rules. You need to write runner of your own choice.

Runner: PHPUnit

Personally I recommend using this runner as it is quite easy to configure, and almost each project is shipped with that library.

• (If not already) Install PHPUnit:

• Create a test case in a directory of your choice. I prefer to configure it in tests/Architecture/ArchitectureTest.php:

• Create a new test suite in phpunit.xml:

• Add script to composer.json:

• Now you can run validator with command:

Concept

Unlike other modern OOP languages like Java and C#, PHP has no concept of packaging inside one project. The only thing are folders, but they cannot be restricted by scope modifiers.

As mentioned earlier, project can be a monolith application, but without any structure projects can quickly become a spaghetti code.

Modular approach

The idea is that project source code can be bundled in Modules. Each module has a Path and corresponding PHP Namespace.

Consider such project:

You can see that project has been divided in modules: Armap and Core. Architecture validator can reflect such situation:

Each module can contain set of PHP classes, interfaces and traits that will be analysed.

Rules

Architecture validator provides set of validators to check for common used approaches. They are called Rules and they can be found in src/Rule/Extension

CoreModuleRule

Rule is assigning one module as Core module. Rest of registered modules are treated as Submodule.

Checks:

• Core module cannot depend on any Submodule.
• Submodule can depend on Core module, but cannot on any other Submodule.

This approach allows creating easy to maintain packages. Dependencies are only in one direction.

DomainDrivenDesignRule

The rule is enforcing structures typical for this module architecture. Typical structure looks like that:

You can read more about the structure here.

Further, {Domain, Application, Infrastructure, Presentation} shall be called Layers

Checks:

• Domain layer cannot depend on any other layer.
• Application layer can depend only on Domain layer.

DomainForbiddenDependenciesRule

Domain is a heart of the system, and should not be polluted with unstable libraries. It should be well-tought process. The rule ensures that developers thought about implications of adding dependency into Domain layer.

Quote:

You need to add dependency whitelisted to ignore the error.

Development

• Clone the repository

• Install dependencies

Release a new version

• Run composer mr (static code analysis) to make sure library code is up to standard.
• Add changes
• Commit changes
• Tag the changes
• Push to master