ArchLens (GitHub) is a project that aims to help developers keep track of the evolution of the structure of their systems by allowing them to quickly define module views and then visualizing their evolution.
An example of defining views with ArchLens:
Once this view is defined, we can reuse it in various environments.
GitHub Workflow – uses the CLI tool under to generate architectural diff views and insert them into every PR
VS Code Extension – live interactive diagrams in the IDE – one can jump from individual dependencies to source code
It consists of three components:
A vision paper is written by Mircea about the project.
Multiple students have contributed to the current version of Archlens in their master’s thesis and research projects:
Several possible future directions for ArchLens are:
It would be good to be smarter on which views are introduced in the PR by the GH action. Currently views are introduced even if there is no visible element being added or removed in that view.
Looking at a PR from Tiago I see that he introduces a new dependency from API to core:
Looking at this view, I have a strong curiosity: “Why is there a new dependency between api and core?”. It feels like maybe I should be able to see what is this +1 is! What is the simplest way to answer this question? And then… should it matter? After all, it’s architecturally correct, there’s a strong dependency between the two, there’s just a new call, it’s fine. The details are in the code diff. Or?