-
Notifications
You must be signed in to change notification settings - Fork 302
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add mandatory dependency settings to layeredArchitecture()
#892
Merged
codecholeric
merged 2 commits into
main
from
support-layered-architecture-dependency-exclusion-strategies
Jun 22, 2022
Merged
Add mandatory dependency settings to layeredArchitecture()
#892
codecholeric
merged 2 commits into
main
from
support-layered-architecture-dependency-exclusion-strategies
Jun 22, 2022
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-layered-architecture-dependency-exclusion-strategies
branch
from
June 18, 2022 15:35
afa4c95
to
aea00a1
Compare
codecholeric
force-pushed
the
support-layered-architecture-dependency-exclusion-strategies
branch
from
June 19, 2022 14:17
aea00a1
to
5b6d4bc
Compare
Looks good to me. No remarks. |
The tests for onion architecture and layered architecture are quite unrelated except for some common test infrastructure. In the end these are two classes housed inside the same umbrella class, but that does not mean we have to test them in one single test class. Having a single test class makes it harder to understand which test method belongs to which class. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
In particular, since adding the possibility to define forward rules within the layered architecture (e.g. `whereLayer(..).mayOnlyAccessLayers(..)`) there has been quite some confusions about how to deal with false positives, like dependencies to `java.lang.Object`. While it is generally easy to exclude those via `.ignoreDependency(..)` this does not seem to be very intuitive for users as there have been multiple GitHub issues about how to deal with those dependencies. We now "force" users to make a (well-documented) decision how to deal with dependencies right when defining the layered architecture. The three predefined choices should cover the vast majority of user use cases (similar to `PlantUmlArchCondition`). For special cases where these options do not suffice it is always possible to simply pick `consideringAllDependencies()` and do fine grained `ignoreDependency(..)` calls later on. Signed-off-by: Peter Gafert <peter.gafert@tngtech.com>
codecholeric
force-pushed
the
support-layered-architecture-dependency-exclusion-strategies
branch
from
June 22, 2022 11:53
5b6d4bc
to
7529901
Compare
codecholeric
deleted the
support-layered-architecture-dependency-exclusion-strategies
branch
June 22, 2022 15:08
TomerFi
added a commit
to TomerFi/alexa-skill-shabbat-times
that referenced
this pull request
Oct 7, 2022
TNG/ArchUnit#892 Signed-off-by: Tomer Figenblat <tomer.figenblat@gmail.com>
TomerFi
added a commit
to TomerFi/alexa-skill-shabbat-times
that referenced
this pull request
Oct 7, 2022
…#652) * build(deps-dev): bump archunit-junit5 from 0.23.1 to 1.0.0 in /lambda Bumps [archunit-junit5](/~https://github.com/TNG/ArchUnit) from 0.23.1 to 1.0.0. - [Release notes](/~https://github.com/TNG/ArchUnit/releases) - [Commits](TNG/ArchUnit@v0.23.1...v1.0.0) --- updated-dependencies: - dependency-name: com.tngtech.archunit:archunit-junit5 dependency-type: direct:development update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> * test: fix failing test after dependency breaking change TNG/ArchUnit#892 Signed-off-by: Tomer Figenblat <tomer.figenblat@gmail.com> Signed-off-by: dependabot[bot] <support@github.com> Signed-off-by: Tomer Figenblat <tomer.figenblat@gmail.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Tomer Figenblat <tomer.figenblat@gmail.com>
6 tasks
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.
Ever since
layeredArchitecture()
supports rules on "forward dependencies" (i.e.whereLayer(..).mayOnlyAccessLayers(..)
) there has been confusion about how to exclude false positives likejava.lang.Object
. While excluding these dependencies can be achieved byignoreDependency(..)
this does not seem to be an API that is easily discoverable.We now make it mandatory to choose how to treat dependencies right in the beginning. This way users will be guided to those considerations and be made aware of pitfalls as well as have an easy predefined option how to ignore false positives.
This will be a breaking change, since existing
layeredArchitecture()
definitions will not compile anymore without adding the choice of how to treat dependencies.Resolves: #887