Low-level Design

After understanding the high-level structure of a system, it's time to explore low-level design.

While high-level design focuses on the overall architecture and the interaction between large components, low-level design dives deeper into the specific implementation details.

This is where we define how the individual parts of the system work together, down to the level of classes, functions, and data structures.

Why Do We Need Low-Level Design?

Low-level design helps in transforming the abstract, broad ideas from high-level design into something more concrete that developers can work with.

In an e-commerce platform, for instance, the high-level design may tell us that we need separate services for managing products, orders, and payments. However, the low-level design will detail:

• What classes or data structures will represent these entities (e.g., a Product class, an Order class);
• How methods or functions will interact (e.g., a function to add items to the shopping cart, or another to calculate shipping costs);
• How the database will store and retrieve this information (e.g., database schema design).

This process ensures that the platform is not only functional, but also efficient and easy to modify as new features or requirements emerge.

Example

In the high-level design of our e-commerce platform, we identified that the Order Processing component handles customer orders and manages their statuses.
Now, let's explore what this would look like in low-level design by defining specific implementation details.

In the low-level design, we need to break down how Order Processing works, including what classes will be involved, what data they will manage, and what functions will handle specific tasks like creating an order, updating order status, and calculating total cost.

So we can create the Order class as follows:

Attributes

They represent the specific data elements that define the class. In our case, the Order class can have following attributes:

• orderId: unique identifier for the order;
• userId: identifier of the user who placed the order;
• items: list of products included in the order;
• status: status of the order (e.g., "Pending," "Shipped")
• totalAmount: total cost of the order.

Methods

They define the behavior of the class. In our case Order class can have following attributes:

• createOrder(userId, items): creates a new order with the specified user and items;
• updateStatus(orderId, status): updates the status of an order;
• calculateTotal(): calculates the total amount for the order Represent the specific data elements that define the class.

We can also define the following dataflow:

• Adding items to the order: when a user adds an item to their shopping cart, the addItem() method in the Order class is called. This method updates the items list with the product and its quantity;
• Calculating the total: after adding all the products, the system calls the calculateTotal() method, which iterates over the items list and sums the prices of the products (using the getPrice() method in the Product class);
• Updating order status: as the user proceeds through the checkout process, the updateStatus() method is called to update the order's status at different stages (e.g., from "Pending" to "Paid", then "Shipped").