Intro to C4 Architecture Diagrams and C4 PlantUML extension

i'm going to cover how to draw an architecture diagram or how to reason about architecture using the tools that i usually use [Music] one of the things about you know creating great architecture is that if your notations are sorted out then your architecture also usually is comes out good this is because your notations actually influence the way you think and in this video i'm going to cover like and i've been meaning to do this for a while now i'm going to cover like the notations that i use and the tools that i use um to create you know architecture diagrams like and they're not like super complicated tools like archimate or um they're not like very specific uml diagrams although i do dwell into or dive deep into uml when it comes to code level diagrams but when you are talking about like a 50 000 feet view and then double clicking deeper and deeper i used like very simple tools that really helped me think about architecture and the tools that i use are mostly you you know modeled or helps model us towards like static diagrams over dynamic diagrams which is they really help us capture the structure of the system and then we dive deep into once we have the structure out you know when you talk about structure and you talk about behavior there is always like an interdependency between the two but you start off with some high level idea of what you want out of the system and then you dive deep into you know how the system is structured in order to achieve that goal and that's that's how you really reason about architecture how you reason about systems or how you you know generally reason about things right you have like a goal at the end state of the system and from that end state at a current starting state that you have you you know you think about how you can get to that end state and modeling and diagrams are like like a way to visualize those steps one after the other right and so uh the the tools that i use as i said are like pretty basic like i start off with using plant uml i use visual studio code which just helps me visualize the plantar code that i'm writing and on top of that i also use a particular diagram notation called as the c4 diagram so it's nothing complex i'll dive deep into that but along with that i also use like a plug-in for c4 diagrams right so now let's like i want to just briefly touch up on what c4 diagrams are but before that i'll talk about the c4 diagram plug-in for plant uml right so this is a plug-in here uh the github link will be in the description of the video uh it's by ricardo neipel it's called c4 plant uml and it's a brilliant plug-in that you can you know put along with plant uml to enable c4 diagrams on plant tuber right so let's get started with some very s you know basic you know plant uml diagram that shows you know various types of uh you know c4 diagrams right so i want to start with you know just saving this file as a puml file or a plant your milk file so that um you know all the [Music] code completion stuff comes up right so i'm going to save it as context dot plant uml so context system context diagram is the first diagram that we start off with the other thing is in order to set up autocomplete for visual studio you will also have to install a extension or plug-in on visual studio called planned uml right this is like a brilliant uh plug-in for plant emil that you know gives a lot of coat coloring you know a lot of features that you know really help you with uh working uh with plant uml it all it has basically some dependency on plant uml as well but yeah it gives you a beautiful way of you know visualizing your planned email diagrams as and when you type and it also gives a auto complete on plant uml uh code right so uh once you have this visual studio set up once you have planned tml extension setup all of these things will be in the description of this video once you have all these things set up you can just uh you know go back to the context diagram that you have the context diagram that we created one more minor thing is that in the plant your ml plug-in that i talked about [Music] this is for plant table not for visual studio code setting up that plugin is super simple you just have to copy this url and you know put it on your platinum encoder you get all the macros along with it but the one one thing that i want to talk about is you can add snippets for visual studio code this this really helps out with the speed at which you can you know build your plantar diagrams although these are not like super mandatory stuff uh they just help you with the productivity uh when you are using plant uml uh the link to this plugin will be put in the description but uh yeah like a high level you just have to put this enable this snippet in visual studio code as well and it's a super simple uh to do that right there are instructions in the github for that particular plugin and you can just like go through that and you know figure out how to do it yourself uh now i'm going to start off with a quick plant your middle diagram so the snippets are all here now so when i do like a start email it will give me a suggestion uh what suggestion of the autocomplete suggestion and i'll say it's a blogging context right so this is the first diagram that we are going to have this is called as a context diagram right the context diagram is basically a 50 000 feet view of your system right so this basically talks about who are the actors in your system and what are the operations that those actors are doing on your system right you can think of this as like a use case diagram in you know in the uml context so you start off with you know defining an actor right so let's say you know you have an actor um now if you saw how the auto complete work the auto complete work because of the planned uml extension uh so before that i need to include this manitobal extension in the plant uml file it's as simple as just copying and pasting this url so once you do this you have all the plantar mil macros in your in your that plant your milk and process so now you can just hit person and you know the autocomplete works and you know you can type you know some alias let's call this as an author and i'll say this is the label will also be as an author and then i'll say hey we also need a system right a system we'll call it a blog and a blogging system okay or let me just call it acme blog so i mean when you hit uh the platinum will plug in automatically renders the diagram that's there so if you can see the diagram come up it basically talks about a person called author and a system called acme blog right now in the system context diagram you basically define what is the action that the author has on the system right so you do that by defining relationships right so you can have a relationship or you can have a relationship with the technology i'm going to start off with a relationship in this relationship i'm going to say author and to the system blog and the action that they can do is like say create a post right this basically means that the author uh is you know passing some request body to create a post in you know the acme blog so this basically creates like a arrow from the author to the blog and with the title saying you know create poetry this basically says that the actor person can create a post on the system blog or the acme blog right the second thing is like we can have a relationship with technology as well this basically allows us to specify the technology through which this particular action can take place so you have like say the update post and let's say it happens over http right so this basically tells us that hey this particular update post call happens over http it could be rpc it could be like whatever other means in which you know the the author communicates with the blog system right so if you can see you see that the update post has also come up and there's a create post and then let's introduce another actor called as a reader right a reader is someone who's external to the system who will be basically reading the particular blog right so a reader has the you know ability to read a blog so uh so let's say read post and you know they'll they'll be reading again on top of https both will be https so they will be reading these blog posts on https by say opening a particular url so the same thing also like comes up in the diagram once we you know update it so you can see like there's a person and there's an external person who's a reader and the person is basically able to create a post and update a post the reader has the ability to read a portion all of these things happen on the system called as acme blog right so this is like the 50 000 feet view of your system right you can add other use cases also like say a delete post and stuff like that but you know to keep this uh video shorter let's not like cover 10 different use cases let's just stick to you know these three use cases because the intent behind this video is not to really talk about a blogging system but the intent behind this video is to you know communicate how uh you know c4 diagrams how plant your ml and how the ecosystems look like and what are the notations that really help you think better about architecture right and obviously we can have that this is a plantable feature where you can add like a title on top of your diagram that helps you uh you know just like put that on top of your image so that when you share out the title also comes as a part of the signature too right so you have that particular blogging context um you have the actors you have the external actor and you have the system and this is like the as i said this is the 50 000 feet view this is basically there is a one abstraction called as the block the acme block and what are the you know various actions that these actors are taking on that particular blog um you know it's demonstrated here but you know this is like the fifty thousand feet view now next you have to go a little deeper right you want to understand what are the various components of this you know uh acme blog that basically allows these set of behaviors to you know occur in the system right so for that the next type of diagrams that are there are called as you know these container diagrams now you have to note that container in a c4 diagramming context is not the same as the container in a you know docker context right while they are like more or less similarly containers can be thought of you know separate deployed services right whereas containers and docker or kubernetes world are you know the things that are basically running an isolated set of code right so now if you think about it container can be the very very very high level they can be thought of as a service right so in this acme blog you know we have to think about what are the services that are really required in order to create a post update a post read a post and stuff like that if you think about it this create update and read and stuff like that are like more or less since you know the system is simple enough can be encapsulated within just one service but you know in in reality most of the you know systems are complex and they can have you know multiple services even in if you think about like a blogging system you can like make it a little more complex by adding a search feature and a service that is responsible for doing search you can have a notification feature that basically notifies various readers when a new blog post come and that can be handled by a separate service and n number of things like that so you know just to make the discussion uh more prominent and show some other features of you know how c4 diagrams can look like that i'm going to add two more use cases to this particular blogging system the use case one is going to be it's going to support search and use case 2 is going to be that it's going to support um notifications in some shape or form right um so that's that's like in order to dive deep into that like we can go into the next uh you know diagram called as the container diagram but before we do that like let me just add those use cases here as well just to you know ensure that um the system has some more meat into it right so i'm gonna call i'm gonna say that the blogging system itself will notify the reader and i'm going to say hey this is going to use email as a technology right and the other use case you know you can have it as a reader can do a search on search posts and again it's going to be on https and let's like uh more like you know update the platform the whole reason for doing this is again to show uh multiple containers and not just how one single container um in our you know blogging system so like i've made this a little more meatier i have added create post update post as you know the actions that the author a person or author actor will do and then i've added like some more features like a search post and a notify of new post um whenever like a reader are those you know features for the reader right so as i said like let's dive deep into you know the second type of diagram which is called as a container diagram as i already talked about uh the container diagram basically shows the various services that are there in the system right so i'm going to create a new file i'm going to save it as container.pml pml basically you know helps visual studio know that video studio code know that this is a plant you will find i mean this container diagram i'm gonna say you know it's called as blogging container i'm just gonna call it blogging container which basically means that this is the container diagram all right and then what i'm going to do is let's let's just get started with uh you know the blogging content now in any case you know it's always prudent to have your actors um and you know show them that they are doing some action on the system the reason is it just helps you reason about things much better so now you have like a system boundary system boundary is like basically encapsulates a set of containers in this system boundary i'm still going to call it as block and i'm going to call this as acme block right and within this system boundary let's say we have so this system boundary basically encapsulates multiple services under it right so we talked about a search use case we talked about a notification use case and we talked about a simple uh crud use case that we had right again i need to include this particular url for the diagram for the macros to come up um so now uh in order to you know think about these different use cases they seem to have their own you know bounded context right like a search is a different bound context compared to a notification and that is a different context compared to create read update and delete of a particular you know blog post rate so now let's start off with like the core entity that we have in the system which is the blog and you know we'll have like a blogging service right the blogging service basically will allow crud on top of all these blog posts right so let's start off with like a container now notify notice the word it's called container i'm going to call it as blog blog service you can use camel case you can use you know you can use whatever snake case kebab case that's your choice i'm just more comfortable with uh camel case i'm gonna use that so you call this as a blogging service it's basically a service that enables blogging for the user and let's say the technology that we are going to use is uh this is a you know a typical uh drop wizard or a spring application right so we'll call it as drop wizard this is like a plain old drop wizard we can add uh yeah this could be like a simple drop wizard beard application so now you have like uh you can see that the diagram has you know updated itself with uh the blogging service details right now let's let's let's let's dive deeper into this system right let's create an action on the system uh which the author is gonna do right let's say uh let's create that's that's basically depicted by a relationship so we have a relationship from an author to the blog service you can this cannot this will obviously be like load balance you know there will be like a elb sitting in front of it all those things can be shown in like a deployment diagram not really required in this particular diagram and we can say that the action that the user does is like or the author does is the create post and you know sends the post details again these are like these these diagrams increase in the you know detail as they go deeper and deeper at this level it's not really necessary to show the payloads that go from the author via front end to the blogging system right um so therefore uh at this point of time we are not going to like really talk about you know what are the data meta data that goes in the create post request that comes way down below when we talk about a type of diagram called as the code diagrams okay now uh like here also if you see the relationship is between an author and a blogging blogging service but in reality it's never going to be directly to the backend right there's going to be like a you know front end like an admin panel or something like that let's let's depict that as well right let's create like an admin panel where you know the authors are going to [Music] authors are going to create the post and stuff like that and then the admin panel uh the admin front end is the one that's gonna talk to the back and we'll say it's you know on our front end based on react.js for example so the author then gives like a create post on the admin panel and the admin panel is then going to communicate to the blogging service uh saying create post again as i said uh the granularity details you know come in the subsequent diagrams not in this diagram right now this is just like the next level from the system context right we we go deeper and deeper and become more and more granular and that's the way how you reason about systems right you don't like start getting all you know granular about details from the get go you start with a you know 50 000 feet view you then go to a 25 000 feet view and then you finally go into more more in detail and finally you end up with this actual code which is the most detailed thing that can be there so now if you can see uh the author did a create post on the admin front end the admin front end subsequently calls the blogging service um which is a back-end based on your drop wizard and now let's say blogging service is going to store it in a db right so we have a container db right um and this this is basically uh so this basically is the database for that particular uh container apologies i have basically forgotten what's the actual yeah it's container tv there's a alias that's missing there so basically you add a container db and that should yes there's an alias missing but yeah this container db basic is the one that you know you'll be using to represent a database right so let's say we are going to go with like a a mariadb again i apologize for you know forgetting the syntax for this it's been like uh yeah i don't think they have really given uh syntax i'm just gonna call it uh blog bb all right um i'm gonna say a blog database uh let's see if this works if not i'll have to dive deep a little to find out you know watch the exact syntax for that but yeah let's let's hope that you know this actually works or you like it just like yeah so there's some issue with the company yeah okay this basically also needs a technology along with it so i'm gonna say hey this is based on maria or my sequel right this is a mysql database let's see let's see if this works great again i apologize i forgot about you know the syntax here but i think uh yeah we are good with it now so now um the blogging service let's say it eventually writes on to this um you know the blog the blogging service actually writes down to the blogging dvd right so we create a relationship um let's say we also mention the technology we we go from blog service to a blog db i will say [Music] insert so the terminology here is more you know database specific we have insert statements but in crud we create some create an entity right so therefore i'm going to call it as insert post row just you know make sure that we are like in line with how the database terminologies are and it's let's say it happens over a jdbc connection right which is our technology now it couldn't no it's not necessarily directly jdbc you could have like a hibernate or a jdba layer on top of it that you know it does the connection cooling and stuff like that but at a very raw level it's going to be like jdbc is going to be used to you know make right to this particular database so now if you can uh if you see uh there is like a clear you know direction from the author to the admin frontend and then to the blogging service and then finally to the blog database uh you know just to make it clearer i'm going to call it as blog db right it's just like a database name for you know the database which stores the particular blog blog related information right so this is like one particular user behavior that is you know demonstrated with this particular diagram but one key thing to note is this type of diagram the container diagram is not the ideal diagram to understand how a particular user flow works right that's a dynamic diagram now what this diagram particularly helps is to you can just take like a couple or two containers and see what are the communication that happens among them it's it's not an ideal diagram to track the entire flow from create till the database because as the system gets more complex there's going to be more arrows here sometimes semantically you can you know figure out what is the particular flow of you know data but this type of diagram is not really ideal for identifying that to identify behaviors of that sort there are like better diagramming techniques right you can use a dynamic type of diagram there's a c for itself there's something called as a dynamic diagram or you know you can use a sequence diagram in you know standard uml those diagrams are much better at depicting dynamic behavior here we are depicting some static behavior right so now let's say there is another behavior of an update post right so let's say we create an update post as well here right um i'm going to just add a relationship and say update post and then again um let's say the admin will talk to the blog service say update post and then finally you know um the blog service basically doesn't update postpro right so now the use case of update is also captured here and you know the way you understand that hey this is the data flow that happens for update purely comes from the semantics rate like there's an arrow from author to the admin front and saying create post and then there is an arrow from you know admin front-end to blogging service again saying create post and that's how you know you make sense that hey this is the flow that's happening but this diagram does not specifically mention that this does not say that after create post the admin front end does the create post to the blogging service or does a update post to the blogging service right that is something you understand semantically from but a more structured they are the more [Music] proper way of showing these types of dynamic behaviors of a particular user action till its end is more captured via like a sequence diagram over you know a container diagram the container diagram gives the 25000 feet view of what are all the communication that's happening from one container to another container right so from this like particular diagram it's very clear that from a blogging service to the blogging db there is an insert poster going and there's an update post store going right but it never talks about hey create post is triggering an insert post or an update post action on blogging services triggering a update poster on uh jdbc via jdbc on the blogging be right those things are you know much captured much better in a much better way and say you have an activity diagram or a sequence diagram but this is just like the you know the next 25 000 feet view of you know how the system is structured now we also talked about two other use cases right we talked about uh a search use case and we talked about a notify new you post use case so let's let's go to the you know notify post use different if you think about it here um a notify can be like a synchronous call or it could be an asynchronous call via a message queue right so let's say there is a another notification service right we have a notification service here i'm going to call it notification let's see this is a no notification service and this is let's say again based on uh drop wizard okay so drop wizard is a container not drop wizards basically jt container drop wizard is basically an amalgamation or configured jetty for you right so you have your jetty access all those things are configured and opinionate form of those things are is basically to opposite so now you have you know another notification service that's come up in our system right and now this notification service needs to be told that you know hey this is the um thing that you have to notify now there are two ways to achieve this one is that blogging services directly you know calling the notification service and saying hey you know notify all these users but you know the ideal way of going the the issue with that is like what if notification service has gone down right so you have like a highly available or a highly reliable uh message queue in between where the blogging service just dumps an event onto that message queue and uh you know notification service reads from it and you know uses that message to then propagate to the reader now there's a one minor you know thing that i said was that highly reliable message queue and needs to be used in case notification service goes but that's not the reason to use a message queue right if the problem is that the notification service can go down and that's why direct communication from blogging service to notification service shouldn't happen then you make your notification service more reliable more available more fault-targeted bringing in message queue is not the ideal solution for you know such use cases but the real use case for having a message queue in between is to you know make sure that the system is ready for you know proper pubs upgrade many other services like a search service is also interested when a note post is created or updated right now i'm not saying this is my opinion i'm not saying that bringing in a message queue in between because your other services are you know not far tolerant not available isn't a bad solution but just that in my opinion if if you can like increase the quality of your service itself you would rather do that the reason to bring in you know message queues in between is to avoid things like call back health enable proper pub sub in your system right but when in pragmatics you know in being realistic about things it does make sense to bring in you know an excuse in between if you have to make sure that the systems are available uh but you know if you are like a solid high high bar engineering team you would rather make sure that your systems are as reliable as sql server relying on the reliability of sql anyway rant aside now going back to this this architecture right so we want a pub sub mechanism to be enabled whenever like a mutation on the post occurs right and that pub sub system is basically going to be used by say a search service and a notification service so let me like you know bring in a message queue in between now here's the thing uh c4 diagrams does not support like a message queue itself in the diagram but you can just you know for convenience sec use the db diagram and just say that hey this is a message queue right you can just you know put it here say you can call it an event bus um you can call it an event bus and let's say this is built out of kafka so that that comes up in the diagram here um now the two things are happening here right one is uh in the event bus the blogging service will notify the event bus that so the blog service will send an event to the event bus saying post updated right so this basically will send a message from the blogging service to the event bus and the message will be say post updated with some post id along with it right uh well that was right now the notification service basically uh we'll call a read messages it will basically try to read the messages that has come to that particular event bus on a particular topic right so notification service now reads message from that event bus and once the notification service you know reads some message it basically then has to notify the person the external person who is the reader saying that you know new post notification goes to the you know reader and let's say it goes by an email now again a nuances here again you can think of a nuanced list and the nuance is that the notification service might not like directly you know send the message to the reader but there will be like external system in between let's say that external system is something like a twilio so we have like an external system here let's call it video right this is basically the one that will be responsible for um you know sending sms or sending emails for us right so they have all the email integration and stuff like that done right so we have again like external system twilio has come up so we'll say that the notification service will send to twilio that there is a new you know post notification and then we can say hey uh twilio sends to the reader a new post email and let's say it has happens for an email right so now if you think about this diagram think about what we just did right we are also able to show these external system systems that are outside the boundary of the acme blog we were able to demonstrate that also in our particular diagram right and this this is how you know you basically uh let me know let's say relationship will you there's some [Music] issue right yeah so there's some issue with the syntax here which we're trying to figure out failure is already different okay so the problem is when i called twilio early on um it automatically got defined and because it automatically got defined i cannot like redefine it so what i'm going to do is i'm going to take this back here that should fix things for us yeah that that should solve things for us yeah so when i just called you here plant your milk went ahead and created so an entity for it will you but we know it did not allow us to define it again so here you know we have uh basically depicted that the reader how the reader gets a new post notification rate a post update call goes to the event bus and then a read message occurs from the notification service it reads from the event bus and posts it to twilio and then twilio sends it to the external uh actor which is the reader here now one more uh you know thing that we have to add is like the read post right this is an action that the reader takes um so let's let's create that relationship this is from the reader to let's say there is a you know this is that this won't directly go to the blog service but there will be like a front end in between so i'm going to like add that but you know this will just show that hey the reader is making a call read post to the you know blogging service let's say we have internally we need to create another front end that front end will be like the external front end again we'll call it extra fee and it's gonna also enter and let's say this is based out of html like plain old html not likely um responsive web application or anything like that very simple html based website and we have a relationship now the relationship basically has to update to you know the reader asks does a read post on the external fe and the external sc does a read post on the blog service right that's that's how things work now now you know you can like further uh add more features to this use case like whenever a read happens you can again like dump an event and that event can be used for analytics right so here you can see that the external person reader makes a read post call and the read post call goes to the blogging service right now now if you think about it blogging service again has to read that particular row from the database let's let's go ahead and add that as well which basically depicts that you know the blogging service is going to do like a read post whenever like a new um read call is coming from the uh the external front end so this is just going to do a read post roof right that's another you know communication that will happen with the blogging database right so this is this is how you know the container diagram looks like that there's obviously like the thing about architecture is i can keep on you know making this more and more and more complex that i can add like last time i talked about the search use case but adding that will just you know make this diagram even bigger but the value prop that i'm trying to deliver out of this talk is to talk about you know how architecture diagrams are made and not really talk about a really complex super scalable backend for a blogging system right now for most use cases right for the most homegrown blogging use case something as simple as wordpress is more than enough right now the type of system that we are building here is for like tremendous scale and a lot of new features coming on to this blogging system and this is for those types of uses for a standard home user you can just like patch in a wordpress put a db against that and you know you're fine with that rate you can put some caching on top of it and you should be like fine with it now now we talked about you know the container diagram now the container diagram is something like the the 25 000 feet view or the 10 000 feet view right the next type of diagrams are called as the component diagrams right the component diagrams are more granular they are talking about individual services right wherein we are individual containers so a double click on each of the container itself becomes your component diagrams right in the component diagram of your you know rest resources you will have you know the services that actually handle those requests from those resources the you know layers that communicate to the database all those things are you know the part of the component diagram right it's like a further deeper map into how the system looks like now for eighty percent of the use cases i stop at the container diagram it's like really not useful to go further down because the patterns are so evident and so clear you don't really have to model them over and over again right if you think about a simple crud service you are very sure that you know you will have an external and if you follow on like a hexagonal ports and adapter architecture you are clear that you know you are going to have like resource then you are going to have like an api resource that gets dependency injected with a some service and that service will get some dependency injected uh instances of external db client all these patterns are like super clear right you don't really have to model them over and over again but there are like complicated use cases or complicated system interactions that you know you have to model you have to go one level deeper and for those you know use cases it definitely makes sense to you know create your component diagrams right so my suggestion is don't create component diagrams for all your use case but identify those key critical complex use cases there could be critical use cases which are very simple you know very high highly used use cases or high value use cases but they're like really simple to implement you don't really have to you know create a component diagram for those but for those complex use cases which are you know hard to fit in your head you want a way to you know really break that problem into smaller chunks and solve for it then you can like further dive deep into like a component diagram right so in this particular uh for this particular blogging system i'm gonna like dive deep into one use case and that use case is say a create post use case right here i wanna like go dive go deeper into you know how what are the various classes that are going to be involved you know when i'm like doing a create post okay so in order to do that like i talked about the next type of diagram which is like the component let me go ahead and create like a new component diagram i'm going to call it component pml i'm adding the extension pml just so that visual studio code knows that this is a planned uml file now i i keep repeating this i know that but you know i just want this to be etched in you know folks's head so that you know they remember when they are doing the diagrams themselves right they don't have to come back to the video see over and over again i'm just trying to repeat it over again over and over again so that you know i trigger that thought process that hey this is how you have to do it right um yeah let's let's go ahead with the component diagram right in the component diagram as i said we are going to deal with uh the create post use case so we are going to like dive deep on the blogging uh the blogging service right we created a logging service i'm gonna like deep dive on the blogging cell so in order to do that i'm gonna start with a container boundary right the container brown and i'm going to call it as blog service same name that we used before uh so if you if you see right like last time we talked about a system boundary and this time we were talking about like a container boundary right and now i'm also going to bring in this container of admin container here i'm going to bring that in here because admin container is the one that that's talking to this blogging service right but the the difference here will be that you know here i will depict which particular class will be handling that particular request from uh admin front and right um so admin front end was a guy making the call to blog service now i'm going to talk about you know which particular class is going to handle that use case of a create post so if you see there's an empty uh boundary for that blog service right and there is an admin front end container that's that's that's right so now let's let's create like a simple component here i'm gonna call this um this is like a post resource right let's say it's a post resource now the terminology resource is something specific to jax rs um in other frameworks you could have like other terminologies but here let's say there's a entity called post and any and any thread on top of that entity happens on a post resource on that basically the terminal is entity and resource name right so we have a post entity and we will call it as a post resource and this is going to be the technology here is jax rs right as i talked about so now uh the component is clear here so this is a post resource now the admin the relationship that i'm going to write here is that the admin front and ready admin frontend is going to call to the post resource and say create post again i'm not going to go like super deep and you know add the request and response body and stuff like that it's just like super high level um as like the next type of diagrams this is the code diagram right that's when i really start talking about what is the request body what's the response body in the code diagrams you can also have a swagger as part of your code level diagram although swagger is not really a uml type of diagram it still is very low level that it it qualifies as a code diagram right c4 basically stands for context container component code and the code diagram is like the lowest level the finest most granular type of diagram that's there right so now uh we we we depict the post resource here we show that the admin front end is making a call to this post resource it's saying create post right now the post resource let's say uh talks to a post service right i'm going to say it's a post service and the post service is say based on it's uh you know plain old forge operate and i'll say it's a java obvious stuff right there's no specific technology that's being used in it so you have a post service here now this post service again gets depicted in the diagram and we basically show that you know the post service uh the post resource calls the post service to say create worship this is actually a method call that going from you know the post uh resource to a post service now the post service can be like an interface i post service and then there is an implementation of that i post service right all those things are not really depicted in this diagram that that becomes like a further uh that that can be depicted very well in a class diagram of a uml right now you're basically just showing that you know hey a post resource is talking a post resources needs to talk to a post service and i apologize instead of post service i'd written post results here again by mistake um but yeah the intent is to show in this diagram is that the post resource talks to a post service and the post resource is basically telling post service to create a post and this is basically a function called it's nothing but a function call now we have one more component that this post service is you know um calling and that you know component is basically the dow layer right so we have a post down and the technology can be something like uh you know you can use a jdbi dao for this so a post service then talks to a post dow you know the post service stocks to a post dow and the post basically says hey same thing create post right it's a function call say it's a create post function called it now um if you want to say that hey this is not going to be a function call but it's an rpc you can just add a comma and say rpc here for example it's a remote procedure call right it will just get depicted as an rpc but yeah if not diving people it says let's stick to the simpler use case and you know the post services then like making a call to the post now i'm not going to keep it as an rpc i'm just going to keep it as a standard function call now the final thing that you can you know depict is you could have like a component db here um you know the db that's under this particular particular system and you can you can say hey this is the so let's say we'll call it as blog post db [Music] and i want to say hey this is a relationship you know between like a post dow to a blog post db and say this is insert post pro right uh very explanatory self-explanatory of what that actually means now i wrote this as a component but it actually needs to be like a component db um this is going to be like a mysql database that we have here so that that's that's basically you know showing how the call goes from like a post resource or it starts from the admin container right it starts in a way above a create post here it goes into a poster source it does a create post on the post service and then again a create post on a post down and then you know finally goes and sits in the db now if you if you remember there was also an additional use case of um a message event being sent as well right and they went to the event bus so we can have like another client here you know we you know that's also depicted as a component you can have a kafka client or we can have a messaging client right message client you can implement it for you can implement for whatever it is it's going to be like a standard java interface and again like a relationship here is going to be like from the post service to the message client and say post created event okay the this basically tells the message client that you know hey a new post has been created and the message client let's say there's an external uh container for the particular event which again i'm gonna just take it from here since you'd already defined the event quest container so i'm gonna take this bus container just you know put it in here but i'm going to say like hey uh the post service the message client is going to like uh you know message client to the event quest post creative event right so basically this passes a post created event right um so this is you know the the next level right so now as we go deeper and deeper our architecture is becoming more and more clear right how stuff works in the system becomes super clear now we know that you know post service fans out uh you know two calls one two uh dow layer and one to a message client player now you can think about you know various edge cases that can happen here right what if an event goes through to the dao but does not go through the message play do you care about that do we have some you know fall back for it all those you know things are like much much easier to think about now right um or like what happens when the message client is not able to talk to the event bus how should we handle that what happens when you know the post daw is not able to insert a row how do we handle that and a lot of use cases like that you know for every every arrow you can think of the success scenario for it and the failure scenario for it so that way it's very easy to break down you know if the way we thought about this right we started at a 50 000 feet view and we broke it down a little right we went to the 10 000 or 25 000 feet view with the container diagram right now we are coming down even lower right we just came down to like a 500 feet view right now which we are we're very close to the code right and then the next step is now as as and we when we come down and down down you know every scenario we think of all the edge cases what are the positives that can happen what are the happy pathways negative path we you know take two individual components here or we take two individual containers and see all the arrows that go from one to others you know there will be a happy part to it there will be a sad part to it it's you know very easy easy to reason about things now because you know we have broken down a complex system into a much smaller simpler set of components that you know together holistically you know bring out something that is much bigger than the sum of its parts right now like click let's go down to the final you know diagram right the final diagram is the uh code diagram now code diagram is as simple as you know your sequence diagrams that you will have like a multiple uh code diagrams um so for example in this whole create post use case you have like a sequence diagram right sequence diagram is also a code diagram you can have like a class diagram you can have an activity diagram as you can have like so many types of you know code level diagrams the thing about code diagram is it's nothing but your uml diagrams you know your swaggers it's very very granular right so you don't really do it for all the use cases you just do it for you know the important use cases that are difficult to fit in your head right um so yeah it's it's as simple as you know just create this um so let's let's talk about you know the the create post use case itself right so you have a very simple post resource talking to a post service saying create post right um now this can have two scenarios art success in the success scenario basically let's say the post the success scenario the posts post resource gets a response back from post service saying you know success right and the post service then your response back to the actor let's say we'll introduce an actor also actually user freight yeah the user let's say it's a post the source um saying hey create post and you know the you know user gets response back from you know the post resource saying success or you know you can have an else failure post resource gets a failure message from a post service and user gets like the same message back right from the post resource they get a failure and you do an end right again like we can go much much deeper into this but the whole point of this talk is not to talk about you know how sequence diagram works i'm just saying that you know the last last the final step here in your diagramming is you know your code diagrams you can have as many code diagrams as you want you can have as many component diagrams as many container diagrams as many context diagrams as you want the whole idea behind it is you start at a very high level fifty thousand feet view and from there and then on like you you know start dividing your problems into sub problems you know then reason about them at that level right and then further you divide your systems into more sub problems you divide you think about you know those sub problems again you divide them into you know further sub problems right so you're basically dividing and conquering your your whole problem statement and that helps you know you create a much better much robust system right because you're not reasoning in an unstructured fashion you have some structure over your thought process and when you have that structure over your thought process you can reason better you can find those edge cases much in a cleaner way your system architecture just you know becomes more and more beautiful that's the benefit of having you know proper notation we as humans are able to you know reason about things so well because we have a tool called language right similarly we as architects are able to you know reason about our architecture in a much better way because of tools like this because of you know proper diagramming because of proper notation and because of proper communication as well we shouldn't forget the communication aspect of things right because if and only if we are able to communicate properly to our peers you know the other architects of how our system looks like will we be able to get feedback from them right if they have like a very crisp clear understanding of our system right they will be able to find those edge cases that we have not covered and they will not talk about those edge cases that we have already covered and not you know depicted properly in those images right and therefore it makes those conversations much more useful and much more fruitful right so that's that's the whole summary of you know the c4 diagram the tools that we used uh just take a minute to recall what you know what we just talked about um we talked about you know the two links that we have we talked about visual studio code we talked about plant uml we talked about extension to plant uml that enables us to write you know very beautiful c4 diagrams in plant um let's say by default plant ml does not support c4 diagrams the link to that particular extension will also be given in this uh the video description we also you know talked about a plug-in for visual studio code that enables us to you know write you know plant your ml stuff in a very beautiful way right we then uh dive deep into the c4 diagrams we talked about the acme corps blogging system um i'm pretty sure you know if some company implements this type of you know blogging system scaling for them is going to be like a walk in the park right they don't really have to worry about um you know scaling the system up you know that's that's what you know the architecture is responsible for doing that we are responsible for making sure that the systems that we build are like massively scalable the systems that we built are you know meet the business goals meet the long term goals and you know meet the fault tolerance goals n number of system goals that we have and also the long term extends extensibility goals that we have right and you know these types of diagramming notations really help us do that even better um i'm just gonna sign off with saying that you know hey i hope that this type of diagramming really helps you think about architecture in a much better way um i hope you know you found this uh whole video super useful um if you do please share it with your friends share it with your fellow architects share it with you know fellow peers junior developers who are in aspiring to go in the architecture route i'm sure they'll find this super helpful and super useful feel free to drop in any feedback if you have thank you so much

Channel: rpm

Views: 26,610

Keywords:

Id: n-e1FDAtBuM

Length: 63min 9sec (3789 seconds)

Published: Mon Aug 24 2020