kzhen

any suggestions for solo board games? not a genre that I'm familiar with

Hi, article author here, the reason this post has no diagrams is because it isn't about how to draw C4 diagrams but rather about some of the benefits I've found being able to refer to them in different circumstances. Given the traction this post has received I'm thinking of doing a follow up and try to explain the process I've gone through to build the ones my team uses. Would that be useful for you?

Hi, article author here, the reason this post has no diagrams is because it isn't about how to draw C4 diagrams but rather about some of the benefits I've found being able to refer to them in different circumstances. Given the traction this post has received I'm thinking of doing a follow up and try to explain the process I've gone through to build the ones my team uses. Would that be useful for you?

Hi, article author here, we supplement our architecture diagrams with Architectural Decision Records (ADRs) https://github.com/joelparkerhenderson/architecture-decision... in the ADR we capture: - options considered - pros/cons of different options - chosen option - who was involved in making the decision

there are a few other fields like component, product etc these are very useful for capturing decisions and something I should have mentioned in the article.

Hi jrimbault, article author here, like any skill this needs to be developed. As sarchertech says if you already know how to design systems but struggle with the drawing then practice is the key. When I started out the diagrams I produced were messy and not very presentable, but I kept refining them. Take the opportunities you have before you, for example, if you're building a system at work then take some time to try and draw up some architecture diagrams and run them by some people who you think will give you good feedback. Then keep refining them. If it's the later then there are some videos on youtube that introduce the C4 model - the key thing is to pick a method and try to stick with it, whether that is c4 or arch42 etc, try to learn the underlying principles and apply them.

Hi taeric, author of the article here

> On the onboarding story, I'm specifically curious how/why diagrams work more than a bulleted list

the point I was trying to make in the article was that having a visual representation helps new developers to build up a mental model of the different components of a software system. In my particular case the system in question is made up of: 2xAPI, 2xEvent Processors, Event Producer as well as dependencies on external systems. The architecture diagrams are helpful here as the new developers are able to see the interactions between components.

> I love the idea of having a diagram that works as a reflection of the codebase.

In C4 there are 4 levels, the first is the system view this doesn't bear much resemblance to the codebase, the second is the container level, this is where you show the different components that make up a system. It's important to note here that a component is a deployable "thing", e.g. an API, database, powershell/bash script etc. This is where you start to see a bit more of a link between the architecture diagrams and the codebase. My experience of level 3 and level 4 where you start to model the actual codebase didn't bear much fruit and there are tools which can do a good enough job here from scanning the code (particularly in the dotnet world, NDepend does a brilliant job, although £££s)