What is Low Level Design or LLD – Learn System Design

LLD or low-level design is a component-level design process that follows step by step refinement process. The input to LLD is HLD. 

What is Low-Level Design(LLD)?

LLD, or Low-Level Design, is a phase in the software development process where detailed system components and their interactions are specified. It involves converting the high-level design into a more detailed blueprint, addressing specific algorithms, data structures, and interfaces. LLD serves as a guide for developers during coding, ensuring the accurate and efficient implementation of the system’s functionality. LLD describes class diagrams with the help of methods and relations between classes and program specs.

Remember: Low-level designing is also known as object-level designing or micro-level or detailed designing. 

Class Diagram in LLD

In this diagram we basically list out all the entities which can be part of components. Class diagrams are made as it becomes easier for developer to convert it into code.

For instance: 

User Service
             <-- User 
                     <--Profile
                     <--ID

How is LLD different from HLD 

As studied, High Level Design or HLD is a general system design where we do tradeoffs between different frameworks, components, and different databases and we choose the best considering what the business needs and how the system should work, both in terms of functional and non functional aspects . Here we define the components and how these components will be communicating with one another. Hence here we are bothered with generic stuff as follows and not bothered about the code. 

1. Selection of components, platforms, and different tools. 
2. Database design.
3. Brief description of relationships between services and modules.   

How to form LLD from HLD?

As studied above, input for framing low-level design (LLD) is HLD. Here in LLD, we take care of how our components will look like, the structure possessed by different entities, and how different entities will have their responsibility(operations supported). For this conversion, we use Unified Modelling Language (UML) diagrams. Adding to these diagrams we use OOPS principles and SOLID principles while designing. Hence, using these 3 paradigm we can convert any HLD to LLD so as to get implemented.

Roadmap to Low-level Designing

In order to bridge concepts of LLD with real code let us In order to understand how to design any low-level diagram let us understand via the steps:

1. Object-oriented Principles

The user requirement is processed by using concepts of OOPS programming. Hence it is recommended to have a strong grip on OOPS concepts prior to moving ahead in designing any low-level system.  Object-oriented programming concept 4 pillars are must-have to go start learning low-level designing and the programmer should be very well versed with these 4 pillars namely as follows:

1. Inheritance
2. encapsulation
3. polymorphism
4. abstraction

Within polymorphism, we should be clear-cut with compile-time and run-time polymorphism. Programmers should be absolutely clear about the OOPS concepts to depth right to classes, and objects because OOPS is the foundation on which low-leveling on any system is based. Acing low-level design is ‘extremely subjective’ because we have to optimally use these concepts while coding to build a low-level system via implementing coding software entities(classes, functions, modules, etc)

2. Process of analyzing and design

It is a analyzing phase which is our 1st step where we are claying real-world problems into object-world problems using OOPS concepts and SOLID principles. 

3. Design Patterns

Now the implementation of our above object oriented problem is carried out with the help of design patterns. Design patterns are reusable solutions to common problems encountered in software design. They provide a structured approach to design by capturing best practices and proven solutions, making it easier to develop scalable, maintainable, and efficient software. Design patterns help streamline the development process, promote code reuse, and enhance the overall quality of software systems.

Each pattern describes a problem that occurs over and over multiple times in the environment, and their solutions can be applied repeatedly without redundancy.

Why there is a need for design patterns?

These problems have occurred over and over again corresponding to which these solutions have been laid out. These problems are been faced and solved by expert designers in the world of programming and the solutions are robust over time saving a lot of time and energy. Hence the complex and classic problems in the software world are being solved by tried and tested solutions.

Tip: It is strongly recommended to have good understanding of common design patterns to have a good hold over low-level designing.  

Different Types of Design Patterns

There are widely many types of design patterns, let us discuss 4 types of design patterns that are extensively used globally:

• Factory Design Pattern
• Abstract factory Pattern
• Singleton Pattern
• Observer Pattern

It is also recommended to study the below 5 design patterns as these are less required but it is recommended to learn for the basic understanding of the design patterns.

• Builder Pattern
• Chain of responsibility Pattern
• Adapter Pattern
• Facade Pattern
• Flyweight Pattern

4. UML Diagram

They are 2 types of UML Diagrams:

1. Structural UML diagram: These types of diagrams basically defines how different entities and objects will be structured and defining the relationship between them. They are helpful in representing  how components will appear with respect to structure.
2. Behavioural UML diagram: These types of diagrams basically defines what are the different operations that it supports. Here different behavioural UML showcases different behavioral of  

Tip: Important UML diagrams used by developers frequently are as follows:

• Class diagram from Structural UML Diagram
• Sequence, Use case and Activity from Behavioural UML Diagram.

5. SOLID Principles

These are sets of 5 principles(rules) that are strictly followed as per requirements of the system or requirements for optimal designing.  

In order to write scalable, flexible, maintainable, and reusable code:

1. Single-responsibility principle (SRP)
2. Open-closed principle (OCP)
3. Liskov’s Substitution Principle(LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

It’s important to keep in mind that SOLID principles are just guidelines and not strict rules to be followed. The key is to strike a balance between adhering to these principles and considering the specific needs and constraints of your business requirement.