To demonstrate the feature, I selected a repository that most readers are familiar with – wild-workouts-go-ddd-example application. What if we also could generate software diagrams from the code? Moreover, what if we could do this automatically, within continuous integration pipelines?ĭriven by this idea, I wrote a library that generates diagrams out of code with just a single configuration file.
If you work within a Go ecosystem, you are used to code generation. Is maintaining detailed and up-to-date diagrams of your applications’ architecture worth all that effort? And does it have to be done manually? What if we could… Automate it! In my opinion, this is the best approach proposed so far.
Do you get the idea? For more information, go to C4 model site. When you look for services and runtimes interactions, you will go to the Containers one. Consequently, when you check how single service modules talk to each other, you will find it in the diagram of that service Components layer. When searching for a particular address, you usually use a city or even a district map, not a map of the whole country. Depending on the information you are looking for, you can drill down to the specific part of the implementation, the same way you look into geographical maps. C4 model introduces four layers of software architecture visualisation: Context, Containers, Components, and Code. If this concept doesn’t sound familiar to you, there is a simple idea behind it. Even better if it is an easy-to-navigate, map-like C4 model diagram.
If an ideal world ever existed…Įveryone appreciates a well-structured diagram when joining a new, unexplored project. All of that makes this particularly frustrating. Those diagrams notoriously get out of control, storing outdated naming and already-dropped modules while missing their initial readable and well-organised structure. Most likely, you have also thought that drawing diagrams with even the most convenient tools is time-consuming. Each of those changes requires careful alignment of the software architecture diagrams. We update it daily, starting with a simple change of names, and ending with nuke-refactoring, reshaping the entire application. We all struggle with software architecture diagrams, don’t we? Have you ever wondered why? If you ask yourself that question, why maintenance of up-to-date and detailed software architecture diagrams is so painful, you will come up with a long list of valid answers. We’ve been working with Krzysztof for the past two years, and we’re excited to share his work here. Hello! Please give Krzysztof a warm welcome in the first guest post on our blog.
0 kommentar(er)
