Introduction
In this post, I will showcase the process of working on the first e-commerce backend project for the bootcamp that I am currently attending. What I get to work on right now is not actually the first project I worked on in the bootcamp so far, but it is the first project with some difficulty far greater than others we did, since we are actually tasked with creating a first backend that sort of emulates the real-world e-commerce website for selling books. Compared to the first one, it is more challenging, with a far more number of APIs for various entities and being tasked with coming up with the designs of the SW as well. I feel like the structure of the project is still basic at best, since I didn't get to spend a lot of time thinking through the project thoroughly, but I still intend to improve upon it with each iteration for the foreseeable future.
Background
Prior to bootcamp, I had a few experiences of creating a website from scratch, but in every single case, to my dismay, I abandoned them prematurely since it became way too big of a monstrosity to deal with at the end. The main culprit for why I always wound up ruining the project lies in the fact that I simply lacked the knowledge of how to create the SW in a right way. Whenever some interesting ideas come about, regardless of the sheer difficulty of a project, I impulsively took on each idea by facing it head-on and powering through the great deal of the unknown, which caused a lot of headaches, rather than carefully planning everything from the start and learning about various techniques and tools for creating the SW efficiently. Through these unfinished projects and a great deal of frustration, I learned a great deal about how vital it is to systematically approach building the SW from scratch, encompassing every important step in the process of the SW Engineering, from the stage of analysis to maintenance. What I plan on doing in this project is to apply almost all the things I learned about SW Engineering so far from the start to finish, thus actually completing the project.
Data Flow Diagram
I decided to begin the project with DFD. Even though I should have come up with a list of requirements prior to creating a DFD for the SW, I remember learning that DFD is actually a great tool to reveal some of the missing requirements of the SW, by creating a diagram and visualizing how data moves from one to another. Anyway, one of the classes I am taking right now at school recently went over the topic of DFD and emphasized it as an integral part of the SW Engineering. Taking into consideration many different aspects I learned of DFD, I created the first DFD of level 0 intended to showcase the high-level overview of how the system being developed intends to operate.
Let's go over what I did with the DFD above. I am sorry if it is way too fuzzy and unrecognizable, but you can see a number of symbols, whose shape sort of imply the different roles they play in the diagram. In DFD, there are total four symbols that are used - rectangle, circle, open symbol, and an arrow, and each plays an important role that in combination, aids the overall understanding of the system.
Every data in the DFD starts from external entities - a rectangular symbol. External entities refer to anything that is outside the system, and essentially represent a starting point, from the which data originates. For example, in the DFD above, a user makes a request to the system, in order to retrieve information on a certain user. To start the process, it utilizes the web browser to make a GET request with the certain URL and various information needed for inquiring about a user to the system.
There are about eight different groups of functions that I described as processes - you use a circle to indicate a process in DFD. Processes are simply responsible for taking and processing an input, and passing the output to either one of the following types: external entity, data store or process. Let's use one of the processes in the DFD to go over what I had in mind when it comes to designing the system. When an external entity called User sends a request to the system, the first destination it ends up is the process called Authentication Management, which encompasses any logic related to authentication and authorization. Making sure that each user accesses information that it is rightfully authorized to have access to, this process contains the logic of checking the role of a user for every request a user sends to the system, so it is extremely vital for keeping the system secure from being misused by a malicious attacker. Once a user is verified to have access to a certain API endpoint, the request gets passed to another process in the system - if the request is intended to fetch the information about a certain user in the system, then it is appropriate to direct the request to the process of User Management.
With each process taking a data flow as an input, a data flow gets transformed into another data flow as an output with a different name. One of the caveats of DFD is that you can't re-use the same name on two or more data flows, in order to avoid ambiguity in the meaning of the data. Even if the data flow contains the same kind of data after it gets processed, it should still change its name to point out the fact that it has been processed without changes taking place. For example, in the DFD above, after a request from a User entity gets processed by the process of Authentication Management to verify and check the user's identity to allow access to certain resources, it then gets passed to another process, and the process of Authentication Management does not necessarily change the structure of the request, since all it does it to make sure that a user is authorized to have access to certain sensitive materials that the system stores.
Data Store represents a storage that holds the information originating from the process. It retains and returns the information that may be used at some point in the future - for both the long-term and short-term - for various purposes. Let's take the situation in which the system registers a user, with the information provided by a user using the registration form. When the process of User Management receives a request from the user for registration, it first makes sure that the email provided by a new user is not used by another user by going through a list of users. Once it is fully verified that the email provided by a new user is unique, then the system registers a new user by saving the information of a new user, sending the data to the data store called User Store, a storage intended for storing anything related to users. Now, whenever a user provides the credentials used for its registration, the process of User Management verifies them against the existing information of a user and gives a signal whether the right credentials have been provided.
Even though it would be lovely to delve into every aspect of the DFD possible, it would simply take way too long to go over every aspect of the DFD above, so I will stop going over the DFD part of the project, and move on to covering other things I did for the project. For the next post regarding this series, I will go over the E-R diagram and various other artifacts I generated for showcasing and understanding the system in a much more detailed manner.
Top comments (0)