Skip to content

Query Language

base_language

AccessSpecification

Bases: RelationshipSpecification, ABC

Offers functionality to specify which kind of imports between layers in a layer architecture are expected. Access is defined as the layer equivalent of import between modules, e.g. if layer L consists of module X, and layer M of module Y, layer L accesses layer M if module X import module Y.

BaseLayeredArchitecture

Bases: ABC

with_layer() abstractmethod

This is simply a convenience method to achieve proper typing. It can be omitted.

BaseModuleSpecifier

Bases: ABC

base_module_included_in_module_names() abstractmethod

If the diagram contains fully qualified module names.

with_base_module(name_relative_to_root) abstractmethod

Sets the name of the base module that was turned into an Evaluable. This enables the user to not having to include the entire name relative to the root module in the diagram. Example: root module is named 'src' Base module: my_project diagram generated for modules in src.my_project.components: src.my_project.components.A, src.my_project.components.B -> components are named 'A', 'B' in diagram name_relative_to_root: src.my_project.components

BehaviorBaseSpecification

Bases: Generic[U], ABC

Offers functionality to specify whether dependencies are expected or not.

DependencySpecification

Bases: RelationshipSpecification, ABC

Offers functionality to specify which kind of dependencies are expected.

FileRule

Bases: ABC

from_file(file_path) abstractmethod

Set the path to the file containing the rules that should be applied to the evaluable.

LayerBase

Bases: ABC

Offers an entry point to specifying detailed information about Layer Rule Subjects.

LayerDefinition

Bases: ABC

Offers functionality to define which modules a layer contains. Can either be a single or multiple modules.

containing_modules(modules) abstractmethod

If a module is defined as belonging to layer X, then its submodules are also assumed to be part of layer X.

have_modules_with_names_matching(regex) abstractmethod

If a module is defined as belonging to layer X, then its submodules are also assumed to be part of layer X. Note that no attempt will be made to ensure that the regex patterns for different layers are mutually exclusive. Also note that regex expressions can have unexpected results if predicates apply to modules, but not their submodules. This is often the case for regex expressions with negations. Refer to the documentation of the module import feature for more details.

LayerName

Bases: ABC

Offers functionality to specify the name of a yet to be defined layer.

LayerRuleBase

Bases: Generic[X]

Entry point to defining a rule based on a layered architecture.

LayerSpecification

Bases: Generic[LayerSpecificationSuccessor, InputTypes], ABC

Offers functionality to specify detail information about Layer Rule Subjects or Objects.

ModuleSpecification

Bases: Generic[ModuleSpecificationSuccessor], ABC

Offers functionality to specify detail information about Rule Subjects or Objects.

are_named(names) abstractmethod

If multiple rule subjects are specified, this has the same effect as defining a rule per rule subject.

are_sub_modules_of(modules) abstractmethod

If multiple rule subjects are specified, this has the same effect as defining a rule per rule subject.

have_name_containing(partial_name) abstractmethod

[DEPRECATED] Use have_name_matching instead; method will be removed in upcoming releases. If multiple rule subjects are specified, this has the same effect as defining a rule per rule subject.

have_name_matching(regex) abstractmethod

Note that regex expressions can have unexpected results if predicates apply to modules, but not their submodules. This is often the case for regex expressions with negations. Refer to the documentation of the module import feature for more details. If multiple rule subjects are specified, this has the same effect as defining a rule per rule subject.

RelationshipSpecification

Bases: ABC

Base class for different types of relationships between modules, layers, etc.

RuleApplier

Bases: ABC

assert_applies(evaluable) abstractmethod

Calculates whether it (the rule) applies to a given EvaluableArchitecture. This means calculating which behavior is wanted and then checking this to the state the Evaluable represents.

Parameters:

Name Type Description Default
evaluable EvaluableArchitecture

module dependency structure to compare the rule against

 required

Raises:

Type Description
AssertionError

if the rule does not apply to the evaluable object

RuleBase

Bases: ABC

Entry point to each architectural rule.

rule

Rule

Bases: DependencySpecification, RuleBase, BehaviorSpecification, RuleObject, RuleSubject, RuleApplier

Represents an architectural rule of the form Module1 [verb, such as 'should'] [import type, such as 'import'] Module2

layered_architecture_rule

LayerRule

Bases: RuleApplier, LayerRuleBase[LayeredArchitecture], LayerRuleSubject, LayerRuleObject, AccessSpecification, LayerBehaviorSpecification, LayerSpecification, LayerBase

Represents an architectural rule of the form Layer X [verb, such as 'should'] [access type, such as 'be accessed by'] Layer Y The modules that each layer contains are to be specified via a LayeredArchitecture object.

LayeredArchitecture

Bases: BaseLayeredArchitecture, LayerName, LayerDefinition

Can be used to define layers within an architecture that are each comprised of modules. Note that if a module X is specified as belonging to layer L, all of its submodules are assumed to be part of layer L as well.

with_layer()

This is simply a convenience method to achieve proper typing. It can be omitted.

multiple_rule_applier

MultipleRuleApplier

Bases: RuleApplier

assert_applies(evaluable)

Checks a number of rules against the given evaluable and returns an aggregated error message if at least one tests fails.

Parameters:

Name Type Description Default
evaluable EvaluableArchitecture
required