Resources

• Container Diagram

Transcript

[00:03] Alright folks, I really hope you gave that one a try. Drawing diagrams is something that you’re going to do a lot in your architectural journey. So I hope this was a good exercise especially because these container diagrams can also be really, really useful. So I’ll show you my version of the container diagram FullSnack.

[00:23] I used TLdraw for this. This is more of a draft. Not really like that polished version that I would use in documentation, but it would be a good place to start. And I started by drawing the system as a as an empty box here using a dotted box. And I have the components that we saw before. We have the users of the system at the top and the external systems here at the bottom.

[00:46] Then I added the containers. These are the containers that you saw in the description on the project spec and I added also, like since we had already the technologies that they use, I added that information here because that can be really useful for someone who is maybe not familiar with the project. Let’s say you’re onboarding a new member to the team, knowing which technologies, what is a stack of all of the different all of the different containers can be, can be something that is really useful. So and this is a good way to show that at a very high level.

[01:18] I’ve also added the relationships between the containers and the external systems and users. So here I have all of these different arrows with labels as well. Now more specific are also instead of having just one arrow going down to the system that I have one arrow going from the customer to the customer web app on the restaurant to the restaurant web app and from the driver to the mobile app and the same for these external systems here. And they all have labels as well, as we mentioned, is a good practice to keep things as clear as possible.

[01:51] And then finally, I added the relationships, the internal relationships, between the the different containers of the system. So this includes things like for example, registering events, using the web socket server or reading, and writing to the database. Now, one thing that I did here that is not really a convention in C4 is that I added this internal dotted line to represent all of my app clients. This is just you to make it clear that these arrow here affects all of this. And this arrow here comes from this this three different clients, this is just to simplify it a little bit because I didn’t want to have like three arrows coming down and three arrows going up. It will make the diagram a bit busy, a bit harder to figure out what’s going on.

[02:37] But again, this is not a convention. I think it is. Make it clear if you drew the arrows from each one of them, that that’s perfectly fine as well. And again, this is not really about following conventions, but about making it as clear as possible that the behavior that you’re trying to represent or the concept that you’re trying to explain to the audience of this diagram are clear.

[03:00] I’ve also highlighted here our app. This is just to show you that this is the app. This is to make it clear that this is the app that we’re going to be working with. And yeah, that’s my version of the container diagram. I really hope that you spent a few minutes giving this one to try and yeah, we’ll continue to look at this in the future. We’re going to put this into an actual doc. When we document the architecture, we may use a more polished version, but this is a good draft, It’s a good starting point and hopefully this will give you a bit more context about what is actually the application that we’re going to be building.