Architecture DSL

[mihaeu]

Quick draft:

<?php

beforeClass() {
    // setup
    $fileSet = $finder->find(__DIR__ . '/src')
        ->addAll($finder->find(__DIR__ . '/vendor'));
    $dependencies = $staticAnalyser->analyse($fileSet);

    // setup shorthand
    analyse('path1', 'path2');
}

// test
test() {
    $models = defineLayer()
        ->from('Some\Namespace\Bla')
        ->from('/special.*regex/');

    $views = defineComponent()
        ->from('')
        ->from('');

    $controllers
        ->dependsOn($models)
        ->but()
        ->mayNotDependOn($views);

    $util
        ->mayNotHaveDependencies();

    $views
        ->mayNotBeDependentOn();

    package('Vendor/Namespace')
        ->mayNotDependOn()
        ->classesFromDir(__DIR__ . '/../vendor');

    classesMatching('/.*Service.*/')
        ->mayOnlyDependOn()
        ->classesMatching('/.*Provider.*/');
}

Assertions using xUnit i.e. PHPUnit Framework Assertions.

[Merenptah]

Hi Michi,

Looks pretty nice. Some notes:

• dependsOn: For consistency mayDependOn
• There doesn't seem to be any difference between Layer and Component and Package, you intend to add syntactic sugar for all these more or less equivalent notions?

Do you know how you will handle the errors? Since it does not make much sense to define a test for each layer restriction it would be great if all errors in one test are collected and returned in one report.

Best Hannes

[mihaeu]

Thanks for the feedback @Merenptah

I finally got around to actually implement a first draft. Super ugly, but it's a start. Test cases aren't looking too bad: https://github.com/mihaeu/dephpend-tests/blob/master/tests/integration/ArchitectureTest.php

dependsOn: For consistency mayDependOn

+1

There doesn't seem to be any difference between Layer and Component and Package, you intend to add syntactic sugar for all these more or less equivalent notions?

Good question. I was thinking syntactic sugar doesn't hurt, on the other hand people complain when you remove it later on ... hmmm.

Do you know how you will handle the errors? Since it does not make much sense to define a test for each layer restriction it would be great if all errors in one test are collected and returned in one report.

Definitely. I was thinking of:

• may depend on
• nothing else
• may not depend on
• may not depend on anything

That would be for outgoing dependencies. Not sure yet what to do about incoming dependencies.

I added a basic MVC example at https://github.com/mihaeu/dephpend-tests with one violation. Implementation is a work in progress.

Generated using dephpend uml tests/examples/mvc --output=test.png

Test output should be something like:

• Class XYZ from (layer|module|component|package) ABC should not depend on Class IOP from (...) JKL

[mihaeu]

I will stop using issues for my personal feature requests because it makes the project look more broken than it is :sweat_smile: