mihaeu / dephpend

Detect flaws in your architecture, before they drag you down into the depths of dependency hell ...

Home Page:https://dephpend.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Architecture DSL

mihaeu opened this issue · comments

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.

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

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.

test
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

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