Since architecture is code, why not test it? - Ruslan Safin - ArchDays 2023 (Category Architecture)

Interesting and practical report from Ruslan Safin on the topic of architecture testing. The basic logic of the report is similar. Describe the architecture through plantuml notationally C4 Model All this is stored in the repository in the form of source code. (in the same turnip where deployments configurations for k8s are stored) Next, we test in pipelines the correspondence of the drawing in plantuml and what lies in the settings of deployments. (For example, the author shows how it is checked that the list of services in the plantuml corresponds to what is described in the details for k8s.). This allows you to maintain the relevance of what is described in plantuml in reality. In general, you can check the type and parameters of connections, the parameters of deploits, compliance with conventions. Therefore, we describe the basic principles of our architecture and begin to check them automatically.

Ruslan gives the following examples of the principles they have implemented

1. Use of ACL (anti-corruption layer) Pattern - services that implement ACL are marked as adapter in plantuml, and then check that connections with external systems go only through such services.
2. Passive repositories - repositories provide access only on top of the database, they can be incoming connections from services, they have outgoing connections with the database, but outgoing links to other services can not be.
3. External calls must go through the Gateway API - checking by url in the k8s configuration and architectural diagram
4. Recording operations only go through a business process orchestrator. (Kamunda)

Next, you can wind up the checks and other principles that you have adopted for yourself. (and recorded in ADR.). Well, if there are new architectural problems, then you can write another test and then fix the problem.

At the end of the report, Ruslan shared what real problems were solved. Architecture has been updated, as well as brought to the convention n Were removed outdated topics, where only the message was thrown, but not read.

• There were duplicates of external systems that were started in different teams It turned out to calculate the technical debt by the number of tests and services

Anyway, it worked. very simple and clear reportThis can benefit small teams. Using these approaches, you can build architectural diagrams and keep them up to date, as well as flexibly write quite interesting tests for compliance with conventions.

P.S. It is strange that at the very beginning of the report, Ruslan says that no one thought of the idea of testing architecture. This topic has been around for many years and you can read about the books I mentioned earlier. -- "Building Evolutionary Architecture" (first 2017 year)It had the concept of fitness function, but no interesting examples. (I mean, told) -- "Software architecture metrics" (2022 year)There are examples of architectural metrics. (I mean, told) -- "Continuous Architecture in Practice" (2021 year)There was a similar story with architecture tests. (I mean, told)

Read the whitepaper five years ago.Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles"which I mean." told last year.

#Architecture #Software #SoftwareArchitecture #Management #Processes