Allow defining Onion Architecture components by predicates #894
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
codecholeric
force-pushed
the
support-predicates-when-defining-onion-architecture
branch
from
c4c2191 to
6af6dea
Compare
spanierm42
approved these changes
Jun 24, 2022
archunit/src/main/java/com/tngtech/archunit/core/domain/JavaClass.java
Outdated
Show resolved
Hide resolved
codecholeric
force-pushed
the
support-predicates-when-defining-onion-architecture
branch
2 times, most recently
from
2245e12 to
f86eb90
Compare
spanierm42
reviewed
Jun 29, 2022
While these methods are not rocket-science and the delegating supplier is tested transitively by other methods we should still have rudimentary checks that these methods as public API are not broken. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
This class does not really match the generic nature of classes in the `base` package, since it is clearly related to ArchUnit's domain. When some predicates were moved from `lang.conditions` to `domain.core` `PackageMatcher` was moved to `base`, probably out of the idea that then "every place within ArchUnit can utilize it". But in turn `PackageMatcher` can then not use any utilities from `core`, which makes no sense. Or all such utilities will start to creep into `base` as well. In the end, `core.domain` is the next higher layer on top of `base` in the ArchUnit layered architecture. And within `base` there should be no need ever to match packages, etc., since that is already ArchUnit domain specific logic. Since we are about to release 1.0 and can thus break the public API this is a good point in time to move this class back into a more reasonable layer. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
It obviously is a reoccurring task to join some strings together on comma and single quote them as part of rule or violation descriptions. We can offer this through the public API so users can also benefit from it for their custom rules. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
Some users use different conventions, like class naming or annotations, to define the components of their Onion Architecture. To support such use cases we extend `OnionArchitecture` similar to `LayeredArchitecture` to also allow defining components via any arbitrary `DescribedPredicate`. While extending the example I noticed that it might be a good addition to have a more generic `JavaClass.Predicates.belongTo(DescribedPredicate)` method additionally to `belongToAnyOf(Class<?>...)`. At least writing the example would otherwise have been tedious, since assigning nested and anonymous classes to the annotation of the outer class would always be necessary for this use case. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric
force-pushed
the
support-predicates-when-defining-onion-architecture
branch
from
f86eb90 to
6046075
Compare
codecholeric
deleted the
support-predicates-when-defining-onion-architecture
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Similar to
LayeredArchitecturethis will extendOnionArchitectureto not only allow defining components via package identifiers (e.g.domainModels("..some.pkg..")) but also via predicates (e.g.domainModels(annotatedWith(DomainModel.class))ordomainModels(simpleNameEndingWith("Model"))).This will allow users that follow a different convention than packages to identify their Onion Architecture components to also use
OnionArchitectureto assert their architecture.Note that this PR contains a breaking change in a preparatory refactoring, namely relocating
PackageMatcherfrom packagebasetocore.domain.