Intro to Software Architecture | Overview, Examples, and Diagrams

hello and welcome back everyone my name is Gwen and today I want to talk about software architecture if you've watched my videos before or you've been following my channel you might know that I've mentioned that I've been studying software architecture for several years now especially working as a staff level engineer as a tech lead I've had to be responsible for architecting more and more software systems and parts of systems as I you know advance and grow in my career so this has been a really big interest of mine I've been reading a lot of books and blog posts and I'm excited to share with you what I have learned I think software architecture is really important for every developer to know so even if you just have a little bit of experience I hope this video can still be helpful for you and especially if you're interested Ed in someday being a software architect or maybe working in a staff level role so this is my first video on architecture so I want to cover some of the basics and I also want to briefly go over some career advice and also some tips from things that I've learned over the past couple years now I want to demonstrate these Concepts visually so I'm going to be using a tool called eraser to diag as I go along and eraser has nicely agreed to also sponsor this video so while the video is about architecture if you do like the tool then follow the links in the description below to check it out for free for yourself I hope that seeing these Concepts visually will help you understand and if you do have any questions or comments please leave them in the comments below this video or check out my Discord Linked In the description below to continue the conversation software architecture can can be kind of a complex topic so I want to show a couple demos to help you understand it and go through some of the actual tasks that you might have to do as a software architect for these demos I'm going to be using an app that I've used quite a bit on this channel called the curriculum app you can find out on my Faraday Academy GitHub if you look at the readme you can kind of get an idea of what this app is doing and basically it's a place for you to create and manage your own learning curricul and keep track of your progress as it goes and you can see from the mockups here what you're actually doing and how it works and basically I'm going to give some examples where I'm planning this application as if I was planning it from scratch and then also planning a new feature in the way of writing a design doc for this application as a follow along I created this GitHub repo under the same GitHub organization it's called called intro to software architecture and I'll link both of these in the description below as I mentioned I'm using this tool called eraser to demonstrate this and do the diagrams as I go so you can go to eraser. iio and sign up for an account and then the only other thing I did actually was use GitHub sync so you'll have a button here or you can also go into your settings and it's pretty easy to just follow the flow and sync GitHub repository and then you'll see any readmes you have in that repository if you want to practice diagramming though with what we talk about today you can also just create a brand new file like some of these examples down here and then you can just practice creating diagrams so I'm going to go back here and to get started I'm going to go into this getting started in the sections folder let's start by defining what software architecture is it's basically planning for and making technical decisions about the design of a system based off of business or user requirements that can include system design itself it can also include planning for devops infrastructure and the technologies that will be used now I tried to simplify the definition even further into planning and making decisions about how you will build something so if you are the one planning and making decisions then you're kind of leading people from a technical perspective so technically leading and giving the direction for the design of the software of course the architect has to keep in mind that the decisions have to take into account the requirements for the project I think that pretty much sums up in general what software architecture is now what does that look like in practice I kind of made a general overview of what what that might look like there is an upfront piece of software architecture before going into actually coming up with Solutions and creating the architecture proposal and that first piece is reading requirements very thoroughly and researching and interacting with anybody who is a domain expert like a subject matter expert or a stakeholder that you can gain information of or from so it's basically like an investigation and you're trying to figure out all of the details so that you can come up with the best possible solutions for the problems now once all of your questions have been answered you've done some investigating you've worked out the requirements you make sure all the details are there for the requirements then you can move on to step two which is going into a deep state of focus and analyzing Solutions taking into account any tradeoffs that might come with those different solutions and then finalizing your plan of action now I emphasize here going into a deep state of focus because I think this is a critical piece of course in software development but especially in software architecture you're designing the foundation for systems or whatever is going to be built and there's a lot of things to think about and to take into consideration from all the different possible solutions to tradeoffs and as in software development if you're not working in a deep state of focus when you need to then a lot of mistakes can very easily be made and at this stage they can be very costly mistakes so once you've analyzed different solutions compared tradeoffs and you've come up with a plan then you'll put all of this information into a more formalized document for a new application that might be called an architecture document or proposal document or a lot of times from software development you might be used to seeing this term a design document so you can make an architect Ure design document for new features that should include all of the relevant information as well as diagrams and we'll get into an example of that a little bit later and of course once you make this diagram unless you're the only person working as a technical employee then you're probably going to have to get Buy in from other people at the company they could include key technical people and definitely whoever are are stakeholders in that project or at that company or clients so you have to get Buy in from them and that will include getting any feedback and answering any questions that they have I think a lot of times it's a good idea to walk through an architecture plan in person with your client or other people at the company and then especially for larger or more complicated architectural plans you'll inevitably get feedback maybe both from a technical perspective about the design to a business perspective like does this actually meet our business needs or can we make this align a little bit better with such and such objective so it may be necessary to iterate on that plan and then once it is approved by any necessary stakeholders it's the time to hand it off to the engineering teams or engineering leadership and help advise them on creating the plan of implementation so this is just a general overview that might look different at different companies now as I mentioned here the some companies will have an architect or a team of Architects that kind of are managed separately from developers or just specialize in the architecture role but a lot of times I think it's especially with the adoption of agile which includes less upfront planning and more iteration there's more combined roles especially at smaller companies so like the role I took as a tech lead responsible for architecture decisions and planning and writing design docs and things like that but I also work with the developer team and do development work myself some companies have different opinions about dedicated art Architects versus integrated Architects and Dual Purpose roles but I'm just mentioning them because there are many different ways to perform or have the responsibility of software architecture without maybe the title and sole focus on software architecture so before I get into demos there's a couple more things I want to mention first I want to go over the common types of architecture now if you've been around software development I'm sure you've heard of monolith and microservices and I think the easiest way to describe monolith I don't want to go into too much detail but if you're building a project and it's all in one repo and you're deploying it all together it's called a monolith let's say I'm building a flask API and let's say this is a health app and I'm tracking uh user Behavior exercise eating patterns all of that kind of stuff and another feature is that it generates reports for users now if I put that all in one repo and deploy it all as one application then it would be a monolith now if I took that same application and divided it up along logical business verticals let's say I took the reporting feature of that application and kind of spun it up as its own separate application and just made it talk to the core or the main application that I just split it off from that would be creating another service and this architecture is generally known as a microservice architecture where you're basically creating and deploying different Services together but all these different Services actually make up your application now there's some pros and cons to it if one piece of the application is used a lot more than the rest of the application gets a lot more traffic or whatever then you have the flexibility to scale that part of the application independently up or down if you're making several smaller Services instead of one big monolith it can also be easier to update make new changes Implement new technologies CU you're just working with a smaller codebase basically now this term has been a very hot buzzword over the last however many years and so a lot of companies whether they need to or not started to adopt this type of architecture I don't want to get into too much of that in this video but maybe I'll make a followup about that but I would say the biggest con of using a microservice architecture is the complexity and especially if you're at a smaller company or a startup and you don't have someone dedicated to the devops role it can be quite challenging to create and maintain this type of architecture so a lot of times people will start off with the monolith approach and then as needed or where it makes sense later on start splitting things out into different Services one by one and keeping their main application and just deprecating it piece by piece as they split out Services a few more terms or types of architecture I want to point out this one became popular of course with the Advent of the cloud and serverless architecture and it's basically an abstraction on top of servers so that you won't need to manage servers or infrastructure yourself and it can be very cost effective for certain types of projects because you'll only pay for the resources that you use and sometimes those resources just spin up when you need them and will hibernate if you're not using them of course this comes with its own set of challenges sometimes a lot of times for example if you're in the AWS ecosystem creating serverless you're using tools like AWS Lambda which is specific to AWS and you're coding inside of that abstracted environment so you're kind of locked in as they call it vendor lock in let's say your costs increase or you have some kind of need s that aren't reasonably provided on the platform that you're on you want to switch platforms it can be quite a bit harder to switch in a serverless architecture versus just an app that you built and deployed fully by yourself that you could just write a little bit of deployment code and deploy it anywhere else I have some videos on my Channel about serverless architectures if you want to check those out and then finally evolutionary architecture I want to mention this one because this seems to be what people have been talking about for a while now in the software architecture space and it's basically the idea that you can make or design software that's adaptable and prepared for future changes especially in today's agile world where we are constantly iterating um business requirements might be constantly changing we might have to constantly update or change technology so there are ways and tools and methods for us to be able to prepare for that and architect in such a way that it's easier to update our applications in the future of course evolutionary architecture is kind of an idea or set of ideas and different people I've seen have different ways that they specifically implement this so maybe I'll talk about this in a future video but I think the biggest barrier is the knowledge of how to do this like how can we make things that are easy to change easy to add or remove things as our requirements change so I wanted to point this out because I think this is a really important topic that people don't often discuss when people think about architecture it seems like they're often thinking about these green fill projects in other words architecting a brand new application and getting to plan from scratch sometimes these are the most exciting applications because there's more um freedom and fewer constraints so a lot of people want to work on these types of projects but I think more common in software architecture or just in development in general are working on projects or updating systems that already exist now this could be adding new features to a current project which might be partially Green Field cuz you're adding something new but a lot of times it's also updating based off of new constraints or maybe you built something that would handle you know 10 rows in the database per user but now you realize users are actually you know doing a lot more uploads than you thought so now there's tens of thousands of rows per user and when they are pulling this information the page is crashing because you didn't plan for that cas case to happen so now you have to kind of re-architect a little bit and see how you want to handle that another case is where you're going in as an architect to assess problems with an application that the whole application isn't really working out or it's very buggy seeing if if it's better to fix it or build something new and you'll need to come up with an assessment of the situation research some potential new architect Ure proposals and then present that information these are just some ideas and examples that I have from my own personal work and from learning about architecture over the years let's move on to what to pay attention to I would say the number one thing upfront is making sure you thoroughly read and understand requirements I mentioned this earlier but it cannot be understated this is why deep focus is so important because if you miss something you're kind of building the foundation that everything is going to be built off of or you're building the blueprint so if something is wrong with the architecture plan because of a missed requirement that's a great tragedy the second thing is tradeoffs and I think the hardest thing for especially people who are newer in Tech is that they kind of have this tunnel vision where they think the tool or technology that they use and that they like is just so much better than everything else and it's hard for them to see outside of that because they really don't have enough understanding or experience to be able to see and analyze trade-offs because every decision every technology has its pros and cons in terms of cost for the business complexity maintenance so many different things to analyze to decide whether or not that decision is worth it and that's really one critical skill of a software architect is being able to zoom out look at everything from a high level and unbiased perspective to make proper decisions and this kind of goes along with evolutionary design in general it's just important to be able to make systems to adapt to Future changes and I would say also see ahead as far into the future as you can like if you know that a year or 2 years from now your company goal and trajectory is to be in a certain place you can make decisions now to help your future self or to help your future client so the most important things I think to learn if you're just getting started in software architecture is first how to write planning documents so architecture documents design documents it's great practice to write a design document for any piece of software that you're building or maybe a new feature or even a small ticket that you have you can just practice writing a design document I think that doing this also helps stay organized a lot and it's a great tool for effectively communicating ideas to other people the second thing that I think is very important to learn is how to diagram sometimes a visual can help explain something so much better than words on paper or just telling somebody creating a proper software architecture diagram and there there's different types like component diagrams flow diagrams but knowing a few different types and being able to know how and when to create them is critical in the role of software architect and even just for any software developer really I think they should be able to draw some of the basic diagram types because even as as a software developer especially as you progress to senior level or Beyond you're almost definitely having to write some kind of design document for at least new features that you're making next I wanted to show you an example of how we might plan an application and write a software architecture document for it and again I'm taking this application the curriculum app and kind of replanning it so if you go into this curriculum app demo folder in the GitHub repo and this app requirements. MD file you can see this document just has some of the functional non-functional and a couple business requirements for kind of the minimum viable product or MVP of our application I just included some here for having users that can log in log out uh we need to have the ability to manage a curriculum so user can create view update or delete them and then inside of each curricula there should be a name and a goal some other metadata description and then you can add sections and resources as well as projects so I think this is pretty much the core piece of the application and then users can keep track of their progress as they work through their sections and courses so those are the functional requirements of the system that we have to account for in other words what the system has to be able to do now if we look at the nonfunctional requirements but still important requirements to consider things like performance and scalability and of course we have to maintain some level of security for our users and our business and plan this in such a way that it will be maintainable in the future so these are the requirements that I have been given for the application now if I want to be able to plan the architecture for here of course since I built this and wrote this I understand all the requirements already so I can go ahead and start creating an architecture document so I have two templates that I put in this repo that you can use and I'm going to use this one for creating a new project this new project template and it basically just breaks down different sections that you might want to include in your architecture document of course with this template or any other template maybe you'll find it online you don't really have to use every single section on here it's just just a good template to start with and then you can add or remove or change things as needed but you'll probably want a lot of these sections in your proposal it definitely keeps it well organized and makes sure you aren't forgetting things that's why I use templates for everything for design docs or whatever I'm creating something new I already have a template and make sure I don't miss anything and then I can just go in order and fill it out so I actually have this template already filled out over here if you go under design docs you can see the curriculum app Green Field I don't want to do all of this typing live so I actually created this document mostly already and I'm just going to walk you through some of the decisions here so first I describe the purpose for what we're building and the purpose of the document as well so it outlines the architectural plan for the MVP of this curriculum app that we're designing right now and a reminder that this document is for not only the development team but also for potentially non-technical stakeholders and anyone else who might be working on this project and it's really a guide for that initial development and how to build off of it with future enhancements scope is really important part of these documents and it's easy for this one because it's just the MVP of this application and what that entails here are some definitions these are obvious but I just put them here as an example and then if there's anything in here that needs referencing maybe a certain pattern that we're implementing or some type of documentation for this one I just put some documentation here that were of tools that we're going to be using this is the overview of the document if you have a bunch of details here you could put this in bullet points I just put it in one sentence to make this short and now we get to the actual architectural decisions so first this is pretty obvious choice for the stage and scale of our application but we're going to not over complicate things and just use a standard monolithic architecture to simplify deployment and development and then I made some notes Here the business wants us to focus on time to launch and you remember this is from the requirements document that we looked at before and so this points back to it and then so we can get real users on the platform and start iterating which was one of the business requirements that business people wanted us to get real users on as soon as possible and start getting feedback from them so given the scope and scale at this stage a monolithic approach is cost effective and straightforward to implement okay so that's some of the reasons why we chose our architectural style and then who are our stakeholders that we are designing with their considerations in mind of course users and perhaps at this point we haven't interacted with any users or maybe we had a previous version of the application or a ux person that did some user research and then we have have our of course our software developer team and any uh key technical people at the company and then we also have any business owners clients stakeholders so I'm just defining stakeholders here who have an interest in this project here are just some general system concerns that we're keeping in mind performance scalability and security and then I didn't have much to say about the system I didn't go into depth about Docker and um any any of the other things that I'm doing I just tried to keep it straightforward here and then the architectural strategies so um I want to break this one down a little bit more so some of the key strategies so given the current experience of the team and the requirements for this project we will use the following Technologies so I know not all Architects or not all documents will include the text stack some do some don't and some times that's a decision for the team but in this case of course it makes sense to just Define these things upfront this was in the requirements doc some details about the types of data we will have in the application we're also in the requirements doc So based off of that and the experience of the team we made these technical decisions and then we also had some security considerations to take into account when architecting our system so these are some of the decisions we made based off of those things and I think this is really an illustration of tradeoffs we will basically be using some libraries to manage our own passwords and the security behind them our own authentication and of course this will help us ship faster but it's a trade-off it may not be as secure as using a third party service for that but we are planning with the future in mind because we are going to separate some things like creating an oth table with a foreign key to the user table we're going to kind of separate our security credentials to make it flexible so we can just swap that piece out later to use a third party off service when we need to in the future and then how we're handling authentication we're going to use tokens and pass between the front end and the API and that's how we'll check for author I ization on resources and objects so an overview of the system architecture the front end back end and database and then here you can see there's some spots missing or right here 6.2 and this is where we're going to add some diagrams so we're going to add a component diagram of the components of our system and then also we're going to do uh some simple diagram of our database table so an ERD and these are the different tables they're of course we're using so these are collections so we're going to start with four different Collections and because it's no SQL and we can reasonably have um you know maybe two layers of nesting in our tables so for the curriculum this collection we're going to Nest sections and resources just inside of this uh collection so we don't need separate collections for those things and that was one reason why we chose this style of database because of our data and also because of the speed of initial development and then I just broke down a list of the decisions why we made certain decisions of course this document is pretty brief so it's pretty easy to see but it's just nice to have this log of key decisions and just a summary of the reason for each one and then we have some more information any potential risks of course some of the tradeoffs that we're making might cause technical debt since we're focused on rapid development and speed to market right now so we have to take um that into consideration and then this is just boiler plate um nice to have just in case case so now I want to go back and fill in some of these missing diagrams using eraser so this is that same document here I'm going to scroll down to the component diagram and in this section right now I'm in a document here but I'm actually going to open up this right sidebar by clicking both and now I should be able to draw a diagram inside here and put it over into my markdown file so I'm going to draw a simple diagram here and I'm going to start with the user interface section and then I'm going to draw the second layer so the back end which is our node Express app running in the back end and then we have our database layer you could do something similar for a class diagram but I think this makes sense for our project right now and now I need these objects inside so this will be the Authentication and I'm just drawing the simple version here and this will be let's say the curriculum UI and all the pages associated with that and for authentication we're going to have our authentication of course it's not its own service it's all in one backend we can split out if we want to later and for the curriculum it's also going to be talking to different API end points let's see end points okay and then on inside our third layer here we have our collections so we have maybe the users and O collection and then we also have the the curriculums or curricula I guess it's two different words of doing the same plural word a lot in English so curriculum collection or curricul collection okay and now we can denote the relationships so we could come here and say that this is the API calls and then we come we put it to the side and then we come from the backend logic to interact with the database using some type of om so we can say we have read write access to this table in the database and then on the other side we get things out of the database that we ask for well I guess I already put R uh over there or read so that this is actually should go both ways then or I guess I can update this oh wait I can do the two separate arrows so I can put read here read write and then read and then API calls I would the opposite would be the or the return would be the response here so these are the key components of our application and then it's kind of a similar thing through the authentication layers you know the API calls to authenticate and then we reach out to check against the hashed password value for example and then you know we retrieve any information or get a response back and then we send that response and any information back to the end user and then we route them into the curriculum map something like that so this is a simple diagram a component diagram okay now that we created it let's go and add it over here and eraser has these short hands that you can use of course this supports markdown but it also has these short hands so I typed in plus and now I can connect it to a diagram okay so I think I have have to wrap all of this inside this figure wrapper instead of just each section but let me see let me go back here and let's try this I'm just going to call it uh component diagram well I call it ca curriculum app component diagram okay and and that's done and now let me try that again let me try that and of course this is synced with GitHub so I believe if I now push this back to GitHub I can select a branch let me just do that for safety instead of just pushing to my main branch I can just create a new Branch um let me just call this component diagram one okay and I'll create a PR for it and let's just say ads component diagram commit okay push to GitHub let me go back and see oh it's in a poll request so in my file changed it adds this this link that's interesting okay but here is the where is it this is the actual diagram that I added so I'm going to see how that looks actually I wonder if I can just use this link I'm just checking real quick okay so that takes me to the diagram inside of eraser and I guess this can be embedded now so let me go back I'm just gonna oh I can't approve my own PR I'm the one who made this PR but I can just merge uh okay that's component diagram confirm okay now if I go back here oh cool it add this button for me that was the link open and eraser so I can open this document and here's my component diagram but this is just a link so okay so I'm cutting in here and fortunately eraser has some pretty good documentation so I went over and looked at the docs because I thought this was how to embed before but actually it's even easier so I can just come over here to my diagram and just copy it so crl + C and crl +v and now I've just embedded my my diagram with the link to the diagram so now I can get rid of this and yeah this the same diagram and the link so now let me push that and I think let me just push directly to main this time to save time it's pushing to GitHub there's a couple other types of diagrams that I want but I'm kind of running out of time and eraser has this other feature that I want to try out and they have basically an AI generator for docs and I think that should work perfectly with an ERD so I want to just generate uh some kind of simple ER for these tables and I'm going to see how it does so let me come over here to let's come to create diagram and this AI diagram and then I can enter in the prompt that I have so I needed to you design from these four collections um I might just put in the type of database just in case maybe it will infer it from using uh collections here um okay so diagram type um these are also inferred but I already know the type so I'm just going to choose that and then I'm going to click generate here and let's see what it does okay it's generating okay it's actually pretty good I think the code expires at this actually really good I didn't even give it um the list of each field and it just inferred that I do um oh I guess put somehow it put hash password here maybe I made that mistake somehow but we do have so in any of their diagrams in eraser they do have this um domain specific language for you to update um so here it's table definitions that I can update and in users I don't want the hash password that's already in oth and then for this one curriculum it did make a couple mistakes it's mostly right actually um I guess the ID is a string okay that's fine um but sections and resources should be objects I don't know if it has it let me see if it autoc completes do they have Json Fields oh I'm in the wrong one actually okay I meant to come in here they don't seem to have Json B FS oh well it's not a big deal right now if I just I'll look at the Docks but yeah that looks pretty good other than it just having the password here so I'm going to say save this and go back to both and now let me see if I can well here if I zoom out maybe oh okay eraser ERD diagram title so let me just oh yeah copy let me copy this and paste it over here oh I see if I'm going to paste it over here and want more than the link then this has to be a figure that makes sense okay so I can change this there was some kind of option here it says create figure okay so now it's a figure and now I can name it let's see uh just what it is I guess okay so now I created that and I think I can paste yeah okay so now I can paste it over here and now if I make updates over here or I can even add comments or something over here and then that will also sync with my GitHub so I'm just going to push again directly to main to get that diagram over in GitHub and I actually want to see what these diagrams look like embedded that's still pushing let me go back okay so here's the first embedded diagram and I think the second one may have still been pushing so let me refresh again okay there we go there's my ERD it was actually very easy to create I think it probably has slightly better support for SQL databases which is fine I almost always use postgress anyway and this is pretty easy to infer what it is okay so those are two types of diagrams that I just added to my document and you'll be able to see if you check this out on GitHub I just wanted to take a few more minutes now to go into a different template for feature design and this is really the one I more fre frequently use and I kind of simplified this because I work at UH startup so I've been iterating on this document for a while and I basically came up with the sections that I found really useful for general purpose and I used this pretty much every time when I need to um plan some kind of new feature or functionality or if we want to let's say we're going to implement a queuing system instead of the systems we have in place right now um this document just has worked really well for me so I have an an example that I kind of filled in here that you can see so this is a new feature that I've been wanting to add to this curriculum app it's the ability for users to Fork other users curriculums so if let's say I made a curriculum let's say I want to learn um bare metal C or something and I created all my resources and projects everything around there in my curriculum and you want to use the same Cur culum you could just hit fork and copy it and then that way you can track your progress on your own and also make updates or changes to the curriculum and save it for yourself so this is that feature to be able to fork and clone um it's intended to enhance the collaboration and Community aspect of the app Foster a culture of sharing and continuous learning so these just talk about some of the goals of this feature and then Des describes the functionality um the project scope like which pieces need to be changed and it's pretty much I mean we have a pretty small Stacks it's not like we have a bunch of different services so it's going to change every layer of the application I guess I could be more specific in the project scope here um and then here are some strategies uh there's no diagram because I wanted to add it here this is the strategy that was selected to uh implement this feature of course this might iterate or be different based off of a design and ux feedback cuz this is kind of a ux decision a little bit um but anyway I'm sure proper permissions um this is definitely something we have to take into consideration in terms of uh security and privacy and then we need to allow users to modify and save the Clone curriculum independently of the original and then we're going to add the diagram some about the system changes and then then um here are just some notes about the decisions and tradeoffs that we making why we made um certain decisions and then I also added this piece about some milestones for the project if we wanted to break it down okay let's finish the architectural planning let's do the API and database development and then UI implementation and if we had um for this feature I couldn't very quickly think of maybe more Milestones to roll out maybe we could roll out an MVP of this feature and then we have um just to get users starting to use it and then we have version two Etc so back here in diagram we can open this up over in eraser and let me go back to my project here and this so the last one was the Green Field design and now this is the feature example for um forking and cloning curricula and now down here where is the diagram oh here it is it's nested inside okay well that kind of changed oh well I'll change this later um but anyway I want to add a diagram here or I wonder if I I I'll try to just add it nested in here see what happens okay so I'm going to open up the side here and I'm going to start with this diagram as code and kind of tell it what kind of diagram I want I actually want this sequence diagram for this case if you haven't seen a sequence diagram before uh you see these a lot I think especially in authentication or for login log out register off service so you see services like ozero and Cognito in their docs they have um a lot of these types of diagrams so here I just want to um basically denote the different tiers of our system so the client and then the server and then we don't really have any external services so we have the client and then we have our API uh running on the server so I'm just going to change oh right because this is um a diagram that is generated from this domain specific language here so I'm going to update it over here so let's change I'll just simplify this let's just call it front end and then this will be API and API to okay it didn't like that Dash all right so front end to API and then API to uh database and then oh we still have service here actually I'm going to take service and I don't need this really so maybe I can get rid of that yep I got rid of all that and now now see what happens if I take those away okay so now I have the front end API and database and this is of course specific to the feature that I'm building for forking and cloning so I can add let me just add one more tier here to make it a little bit more interesting so I think if I add another layer let's do uh user and let's just say this will be a very clear definition of what's going on so uh clicks yeah uh Fork button and this would actually oh we uh we switch things around here let's change it okay the user clicks the fork button and then the front end sends the data request I guess it's like the fork request to the API and then I'm not sure what this is doing didn't do anything okay so I can get rid of that and then the API will communicate with the database it will um request to duplicate the curriculum of course um well let me see if overflows well yeah looks good okay request to duplicate the curriculum and I could leave the arrows both ways but it kind of the request is one way really and then the other way is wait it's this um and then it responds let's see responds with the new curriculum ID because we've just created a new one that's associated with the new user and then we can from the API right we can do API I don't think I need the icon every time let's see if I can get rid of that cleans things up a bit okay so I'm actually going to clean this up too maybe I can use it for something else but anyway so the API will um go back to the front end oh front end yeah with a a success message I guess success or failure but we'll just leave it at that and then our user is happy because our user can see the new curriculum okay and I don't know how to do everything yet like use dotted lines here but I think this is a a pretty good basic representation of what's going on so now that I have this let me oh yeah open up the document part and where is my diagram okay so I copied it and it's just giving me the link so let me do the same thing as last last time when we did the AI diagram I'm going to just put it in a figure oh come on okay and I'll name this figure um what is this uh user Fork flow ah let's see uh curriculum Fork flow diagram okay so let me copy this now and paste it here maybe it's not pasting because it's nested there we go okay so it can't be nested to paste apparently but anyway there's my diagram and now can I change this to start with five no it just automatically goes to one oh no it did I think I did something else accidentally okay good so now it starts where it should at five those are still nested and I have my diagram so let me also push this let's say to the main branch okay and I have to wait a minute for that to update awesome so now it says I'm in sync again and if I go over here I should be able to see my diagram yep that's my flow diagram of this feature awesome one more thing I just realized is that these embedded diagrams here are actually saved to this eraser folder so you can see all of these diagrams that eraser just created this folder for us and I guess I would have seen this if I had created it a new branch and a PR but instead when I was actually you know embedding the actual diagram I just push directly to main so I just wanted to point that out in case you try this out later a couple other things I just want to mention here again I have some terms and definitions in this document I might add to that these are some common terms that I've just come across and taken notes about as I was studying architecture so they're good to know about and you can use that as a starting point for some of your research a couple other things that I included so career paths so typically if you look at I guess a traditional software architect architect of course I had the other definition the easier definition getting started but it's just a software architect role and then you'll hear of Enterprise Architects working kind of a larger scale organization and now they have all different kinds of domain or other types of uh specific architecture jobs so you've probably heard of solutions architect that's a pretty common One Cloud architect in Cloud providers and then of course there security Architects and network Architects are somewhat separate from software development and then some people debate about these last couple if they're they can really be considered Architects but they do have roles for specifically front-end architect and for backend and this is something I've done before so worked kind of playing the role of an API architect for what we're building and I do think this absolutely matches the definition of an architect and you basically for any of these you follow the same steps of working as an architect exactly from the getting started document that we went through and you're still analyzing things and considering tradeoffs Etc no matter what type Ty of architect you are so generally some of the most important skills for a software architect deep technical knowledge and understanding of application development in whatever domain you are working in um but also you have deep knowledge but also being able to zoom out and look at the big picture which is something a lot of people struggle with and then a critical piece of being an architect is you need to be able to have communication skills for of course describing and breaking down down problems and solutions to technical people but also for non-technical audiences and being able to get Buy in from non-technical audiences stakeholders meaning you have to get along with people and also really be able to articulate your ideas and argue your perspective well and then one more key skill that I think is important for software architecture is to really keep up with new technologies and tools now that might vary by domain like if you're a cloud architect you'll just focus on cloud stuff mostly in whatever domain you're in I think it's really important to keep up with new technology and tools and that way you can really design for the current needs of your users and systems and also prepare for the future and what's coming down in the pipeline I also included this other document about practical tips and best practices so you can look this over some of these things I mentioned before and some of them I just want to emphasize and mention here and then if you go back to the read me here you can see there's this learning resources link and that actually points you to this blog post that I just posted helpful resources to learn software architecture and I just tried to collect some resources and then boil them down to what I thought would be the most helpful and the things I liked the best so here are a couple videos and then some of the books I really like now if you're brand new to not only architecture but also kind of newer to software development I highly recommend you read this book The Missing read me and that includes a section about um just basic um architectural considerations in there and then there aren't uh really many dedicated podcasts but here are a couple podcasts that I like and they include some episodes on architecture actually this one is about architecture but they haven't posted a new episode in a while but I still found some of their episodes to be really helpful here's a monthly newsletter about software architecture that I get um and then I also highly recommend you check out something called the C4 model if you're really getting into architecture and this is just a set of recommendations for how to visualize and communicate about your software architecture in ways that makes sense sometimes it's hard to know how to diagram or what to diagram or what to show to your stakeholders and this system was really helpful for me to learn about that that's all I have for today if you have any feedback for me I would love to hear it you can leave it in the comments below or you can join me on Discord which is also linked in the description below this video I've been waiting for so long to do an architecture video so I'm very happy to be able to finally put it together from the thousands of notes I've been taking over the last however many years and I'm very happy that eraser sponsored this video and helped me to finally push myself to do this dive into software architecture I do want to make a lot more follow-up videos to this topic so stay tuned thanks so much for watching and I will see you in the next video take care

Channel: Faraday Academy

Views: 9,928

Keywords: software architecture, eraser.io, sa diagrams, component diagrams

Id: k3hKLd7vYZ8

Length: 65min 24sec (3924 seconds)

Published: Mon Jan 15 2024