Sure, but there’s a whole dimension missing here. Architecture is more than simply “what", it’s also "why". It binds the context to the requirements and the de

Sure, but there’s a whole dimension missing here. Architecture is more than simply “what", it’s also "why". It binds the context to the requirements and the desired components< their relationships and interactions. Some other comment described architecture to code as a lossy process, and that’s exactly right. A diagram is not "the architecture", it’s simply a view on it, or a "projection of the model" as the c4 folk like to express it as. I just find the idea that we should automate diagram production because diagrams are hard to keep up to date a little quaint, because you hardly ever need to update just a diagram when changing the architecture. So your actual problem is that your design documentation is hard to keep up to date, and that’s a process problem. Generating diagrams from code won’t save you there.