DEV Community

Phodal Huang
Phodal Huang

Posted on

ArchGuard: a open-source architecture governance platform

Over the past 10 years, software architecture has undergone tremendous changes, from the earlier popular monolithic MVC architecture to the so-called 5:5 split, meaning from distributed to monolithic. The fact is, there are a large number of software developers who cannot see the whole picture of the system or change from a single-minded approach. As a result, even when using microservices, the implementation is still monolithic, and they become "distributed monoliths."

Architecture governance has become an urgent issue.

The challenges we face

As a software architect or developer, we face many challenges in architecture governance:

  • Design and implementation mismatch. There is a huge difference between the designed software architecture and the actual implemented architecture. This difference often needs to be coded online or is onlydiscovered later.
  • No norms/non-compliance with norms. As a senior developer, we have a set of specifications,but many team members aren’t willing to abide by them
  • Huge amount of code, making it difficult to identify problems. In asystem created by a dozen or more microservices, it’s often difficult to quickly discover the intricate relationships between them.
  • Errors can occur at every level of the architectural model. Such as API coupling between services, coupling between codes, database coupling, etc.
  • Architectsand developers themselves lack extensive experience. “I know there is a problem, but I can't tell what is wrong, and I don't know how to fix it.”

As a result, we need a platform / tool to help us resolve these issues. So, using our past experience in software development and refactoring, we (DTO’ consultants) started developing ArchGuard, an architecture governance platform, in 2020/01.

Now, it’s open source:

What can it do?

ArchGuard performs layered analysis according to the popular C4 architecture model. That is, on the four different architectural views of System Context, Container, Component, and Code, which are different levels of abstraction that correspond to different audiences, such as developers in the team who care about the code’s internal dependencies, and architects who care about dependencies between components and windows.

Image description

In its final implementation form, it exists in the form of codebases and documentation. ArchGuard is a code-based static analysis tool, which will also be provided by design in the future.

In ArchGuard, we need to create a series of system components first, that is, to configure the corresponding language and GitHub address so we can just scan the code.

Components / Modules

In the component view, we can see the overall situation of a single project, according to the corresponding code submission history, and unstable code modules:

Image description

API declaration and usage:

Image description

The architecture is evaluated through the five dimensions of volume, coupling, cohesion, redundancy, and testing. A series of indicators are used to analyze the system’s situation:

Image description

System Dependency Analysis: Service Map

Note: This dependency analysis method depends on team developers having a unified coding standard.

For microservices, ArchGuard can automatically analyze the dependencies between different services and visualize the dependencies:

Image description

Note: Since ArchGuard used to be microservice architecture, after being merged into a monolith, there can be a situation in which it calls itself.

At the same time, the system can help you automatically analyze which APIs are used and which APIs aren’t (some APIs temporarily cannot be analyzed):

Image description

Currently, ArchGuard can support several limited API call identifications such as Spring, RestTemplate, Axios, UMI-Request, etc.

Database Dependency Analysis: Database Maps

Note: This dependency analysis method depends on team developers having a unified coding standard.

For inter-database dependencies, ArchGuard can parse the SQL calls in the code, and try to match the dependencies with different microservices, and then analyze which services are coupled at the database layer. Due to inconsistent coding standards, we could not identify all database tables in the code:

Image descriptionImage description
Image description

With this dependency, we can see the most frequently used tables in our code. Combined with our functions in code analysis, you can view the call map of the database (in front-end implementation).

Code analysis

For development teams, they can view the dependencies between the project’s modules, packages, classes, and methods on ArchGuard:

Image description

Through the above LoginModuleRepository, you can match the results corresponding to the database.

Change Impact Analysis (*In development)*

One of the features we are implementing is to analyze and configure the system for potential code modification points, and then analyze the impact of changes through dependencies. It can not only help architects analyze the impact of requirements, but also help testers test the content of the system more accurately.

How does ArchGuard handle the functions above?

ArchGuard has two built-in code analysis engines: Bytecode analysis + source code analysis.

  • Bytecode analysis. As the name implies, it analyzes the dependencies in the code by analyzing the bytecode in the JVM.
  • Source code analysis. Meaning generating a specific data structure by analyzing the syntax tree of the compiled language.

The source code analysis is mainly static analysis, combined with the Chapi code analysis engine ( previously open sourced under the refactoring automation open source organization Modernizing. Chapi is based on the syntax analysis implemented by Antlr and supports mainstream programming languages such as TypeScript/JavaScript, Kotlin, Java, C#, etc. As shown in the table below:

Due to static code analysis, some content isn’t very accurate.

Combined with several ArchGuard Scanner ( scanning tools to get the data to flow into the database:

  • scan_git, analyzes basic information such as Git commit history, line count, language, etc.
  • scan_jacoco, to analyze code test coverage
  • scan_bytecode, bytecode analysis
  • scan_sourcecode, source code analysis (including HTTP API analysis, database analysis)
  • scan_test_badsmell, test code for bad smells
  • collector_ci, collects history from CI/CD

Most*important thing *

You’re welcome to join the development of ArchGuard, GitHub:

Discussion (0)