Architecture Assertion
Verify codebase using Konsist API
Architecture assertions are used to perform architecture verification. It is the final step of Konsist verification preceded by scope creation (Create The Scope):
Assert Architecture
As an example, this simple 2-layer architecture will be used:
The assertArchitecture
block defines architecture layer rules and verifies that the layer requirements are met.
Define Layers
Create Layer class instance to represent project layers. Each Layer
instance accepts the name
(used for presenting architecture violation errors) and package
used to define architectural layer:
The inclusion of two trailing dots indicates that the layer is denoted by the com.myapp.business
package together with all of its sub-packages.
Define Architecture Assertions
The final step is to define the dependencies (relations) between each layer using one of these methods:
dependsOn
dependsOnNothing
doesNotDependOn
See the language reference for above methods.
The above methods follow up the layer definitions inside assertArchitecture
block:
Strict DependsOn
By default dependsOn
method works like does not perform strict layer validation (strict = false
). However this behaviour is controlled b ystrict
parameter:
strict = false
(default) - may depend on layerstrict = true
- have to depend on layer
e.g.
Excluding Files
Architecture verification can be performed on KoScope
(as seen above) and a list containing KoFiles
. For example, you can remove a few files from the scope before performing an architectural check:
This approach provides more flexibility when working with complex projects, however, The desired approach is to create a dedicated scope. See Create The Scope.
Include Layer Without Defining Dependency
The include method allows to include layer in architecture verification, without defining a dependency for this layer:
Architecture As A Variable
Architecture configuration can be defined beforehand and stored in a variable to facilitate checks for multiple scopes:
This approach may be helpful when refactoring existing applications. To facilitate readability the above checks should be expressed as two unit tests:
Last updated