<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Architecture on Daniel Genezini</title><link>https://genezini.com/categories/software-architecture/</link><description>Recent content in Software Architecture on Daniel Genezini</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><copyright>2022 Daniel Genezini All rights reserved</copyright><lastBuildDate>Tue, 29 Nov 2022 08:20:00 -0300</lastBuildDate><atom:link href="https://genezini.com/categories/software-architecture/index.xml" rel="self" type="application/rss+xml"/><item><title>Keep your diagrams updated with continuous delivery</title><link>https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/</link><pubDate>Tue, 29 Nov 2022 08:20:00 -0300</pubDate><guid>https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/</guid><description>&lt;img src="https://genezini.com/blog/p/keep-your-diagrams-updated-with-continuous-delivery/cover.jpg" alt="Featured image of post Keep your diagrams updated with continuous delivery" /> Changing software diagrams is hard. The simple act of adding a new box may require us to drag all the existing boxes and reorganize the diagram. This is one of the main reasons to why software diagrams are constantly left deprecated after the first stages of the development process.
In this post I'll show how defining diagrams as code can help in designing and updating software diagrams, and how to automate the process of updating the documentation with those diagrams.</description></item><item><title>Cleaner representation of software architectures with the C4 Model</title><link>https://genezini.com/blog/p/cleaner-representation-of-software-architectures-with-the-c4-model/</link><pubDate>Tue, 22 Nov 2022 05:45:00 -0300</pubDate><guid>https://genezini.com/blog/p/cleaner-representation-of-software-architectures-with-the-c4-model/</guid><description>&lt;img src="https://genezini.com/blog/p/cleaner-representation-of-software-architectures-with-the-c4-model/cover.jpg" alt="Featured image of post Cleaner representation of software architectures with the C4 Model" /> Diagrams are a great way to visually communicate something. However, the majority of software architecture diagrams don't really express what they intend to, lacking description of its elements and with lots of implicit notations only understood by who drew the diagram. Also, they try to express more than one vision (high level, infrastructure, flow order, etc) in only one diagram, making it even harder for non technical people or people outside the project to understand.
In this post, I'll present the C4 model and how it can produce software architecture diagrams that are inclusive to non-technical people, easier to understand and, consequently, better to document our software systems.</description></item></channel></rss>