Architecture linter verifies architectural models for compliance with established design rules and constraints. This enables early detection of design errors and increases architectural consistency across the entire team or organization.
Below you can find a description of the ready-to-use rules. You can download the ready-to-use definitions in JSON format here.
Containers should not have cyclic dependencies
Containers must not depend on each other in a cyclic manner to avoid tight coupling and maintainability issues.
Frontend can not connect directly to database
Data access must be provided through a backend/API layer to ensure security, access control, validation, and separation of responsibility.
Container technology must be defined
The lack of information about technology makes it difficult to analyze the architecture, validate dependencies, and assess technological compatibility.
Container technology must be one of the allowed technologies
The container technology must be from the organization's list of permitted technologies. This rule ensures consistency across the technology stack, limits shadow IT, and simplifies system maintenance and support.
Relationships from external systems to database are not allowed
External systems cannot have direct relationships to the database. Data access must be mediated through a controlled application interface (API/service layer) to reduce the risk of security breaches and maintain data integrity.
Relationship technology must be defined
Each relationship between components must have a defined communication technology. This allows for integration analysis, architectural error detection, and infrastructure requirements assessment.
Every container should have instance
Each container should have at least one instance to ensure it is deployed and operational.
Database container must not have outgoing relationships
Database containers should not have outgoing relationships, because databases should be passive infrastructure components and must not depend on or call other containers. Replication and backup relationships may be allowed as an exception.
Relationship description must be defined
Each relationship should have a description explaining the purpose of the communication. This ensures clarity of the model and supports architectural reviews and onboarding.
Element description must be defined
Each element must have a description of its role and responsibility. Without a description, the model loses its documentary value and complicates architecture analysis.
Relationship technology must be consistent with destination container technology
The relationship technology must be compatible with the target container's technology. This rule prevents incorrect or unrealistic integrations in the model.
Containers must specify SLA / criticality tier
Each container must specify its SLA or criticality tier to ensure proper prioritization and resource allocation.
