Introduction
One of my lecturers once said he was privileged to pay a visit to the designer of the famous NIGER BRIDGE in Nigeria, he (my lecturer) was awed at the simple equations (resolution of forces etc) he the renowned professor, solved for such a gigantic project. Needless to say, "THE NIGER BRIDGE" is one of the longest surviving structures in my country Nigeria.
LESSONS: Every system must be designed from its concept, and system design is not as complex at it sounds, infact it makes things easy all through the process of the actual construction(physical or otherwise).
What Is Software System Design?
Wikipedia says : System Design is the process of defining the architecture, product design, modules, interfaces, and data for a system to satisfy specified requirements.
I think arguably, that this definition is one of the most explanatory piece I have ever read from wikipedia.
Just imagine, that project you did without a proper system design, can you remember how cumbersome it was, sometimes even testing your temper, most especially when someone in the team just dreamt of a feature woke up the next morning and says, "can we just put a button that flies at a tangent to this hidden button in a way it won't have to fly"? You were obviously provoked right? Even if its possible, which is not in this case, do you remember how you had to refactor some functions, breaking some other functionalities on the way, fixing them and eventually spending hours upon hours making sure everything is in sync?
At this point you may ARGUE, BUT FEATURES CAN BE ADDED TO AN EXISTING PROJECT, CAN'T THEY? You'd be shocked that the very reason a holistic and comprehensive system design is needed for every project is for this very reason, scalability.
Designing your system properly, creates room for other features to be added with less stress, infact sometimes or mostimes, you'll end up seeing the bug in your system before it gets to the code.
System Design in the software realm is like everything a skilled craftsman needs on papper. Bringing to life such a product will be breezy.
LET'S TALK ABOUT JARGONS
The above definition mentions some jargons which I think are kindaa simple for an English speaking software Engineer, but damn it! I will x-ray them like we are laymen. Four (4) jargons standout; ARCHITECTURE, PRODUCT DESIGN, MODULES, INTERFACES and DATUM. Hmmmmmmm. Okay Lets pick them one at a time.
1. Architecture: What really is the architecture of a software Application? It's not far from what you know, the plan of a building, how a room links with another, where the stairs should be, where the kitchen should be, you get the point. So the Architecture of an application is obviously the whole software structure, connections between services(if you use microservices) or the relations between data; will the posts be accessible to just the owner, or will there be a comment section, how about the user, will they need to log in before viewing a post. Now at this point its a high level thing. There will be diagrams, choice of technology to use, stating explicitly the connections between this and that. Just imagine you a software engineer having to just come onboard and code, code features, not decide on where this should be or what. Are you thinking what I am thinking?? If it's like this you can build a full functional Auth system in hours with no mistakes, I repeat with no mistakes. System design gets more interesting, with modules.. Lets talk modules
2. MODULES: Just imagine the software Architect has already broken everything into modules, say user, auth, notifications, Orders, posts etc.. Just imagine! You will love your job. You will code and focus on just coding the 'what' a module will contain. Say the user module will have creating users, deleting users, updating users, fetching users.... All you need think about is how to implement this. See how a typical module can be
forget about the cohession and all other jargon you see above, just focus on how simple things can get if all you do as a backend engineer or frontend Engineer, is just to code the functions
.... But oboy! It gets even much more interesting and better.. You don't have to think of the contents.. Because system designs includes conceptualizing the INTERFACES too.. Just what are interfaces. Yeah the third jargon.
3. INTERFACES: The interface like you must have guessed comprises of the classes, their methods, the data access and more. Yes it even gets better; at what point will the user input data? how will the data be handled? how should the user interact with the data? All these and more are taken care of by the interface design in the system design. At this point are you beggininng to have the "Men in my next project I must design my system" feeling? You should. A word of caution though, it's hard work, it takes months sometimes and it requires a thorough understanding of the project requirements. But do not fret, it makes things easy. How about the data that is usually modelled or handled by the interfaces, well don't guess, the system design also encapsulates and explicitly describes this. Let's talk data.
3. DATA: You know what data is, ok, It's me I really don't like definitions which introduces jargon, but what will the user need to supply at registration, his name, his email, his phone number? What will be collected for a post, likes, followers, owner, image, title? All these are datum, and they are explicitly defined in a system design. Men! I love software! So say I am a backend Engineer , all I will do is code, just imagine thinking only about the code, you not only become better at your art, tasks are delivered on time and perfectly.
what your conversation will look like
Team Lead: "Ogaga, here is the module and this function should return users posts, the fields are all in the schema design, and the structure of what to return"
ogaga: "ok".
ogaga(few minutes later): done.
Team Lead: ok, lets see.(runs the test). Ok cool. so what's the time complexity?"
Ogaga: "O(1)".
Team Lead: "How did you achieve that?"
Ogaga. .......
You get the point? We are no longer talking about a field is missing, the users should be in an array, but about speed, efficiency. Meanwhile probably the code will be serving users already.
YOu are right one last jargon is missing, PRODUCT DESIGN
4. PRODUCT DESIGN: You see everything we discussed, every jargon, the architecture, the modules, the datum, the interfaces, the user interaction(which includes the ui designs), everything is conceptualized in the product design. The product design does not describe what has been done, its the first thing you do, usually by the product owners and Tech Team or tech lead or tech contractor. A house is not designed after it has been built, that doesn't even make sense.
So in your next project, if you want speed and efficiency take the time, and meticulously DESIGN YOUR SYSTEM..
SOFTWARE SYSTEM DESIGN IS NOT JUST ANOTHER COMPLEX LAYER, IT's AN IMPORTANT FIRST STEP
HAPPY HACKING!!
Top comments (0)