LLD o diseño de bajo nivel Es un proceso de diseño a nivel de componente que sigue un proceso de refinamiento paso a paso. La entrada a LLD es HLD.

¿Qué es el diseño de bajo nivel o LLDn?

Temas importantes para el diseño de bajo nivel (LLD)

• ¿Qué es el diseño de bajo nivel (LLD)?
• ¿En qué se diferencia LLD de HLD?
• ¿Cómo formar LLD a partir de HLD?
• Hoja de ruta hacia el diseño de bajo nivel

¿Qué es el diseño de bajo nivel (LLD)?

LLD, o diseño de bajo nivel, es una fase del proceso de desarrollo de software donde se especifican los componentes detallados del sistema y sus interacciones. Implica convertir el diseño de alto nivel en un modelo más detallado, abordando algoritmos, estructuras de datos e interfaces específicos. LLD sirve como guía para los desarrolladores durante la codificación, asegurando la implementación precisa y eficiente de la funcionalidad del sistema. LLD describe diagramas de clases con la ayuda de métodos y relaciones entre clases y especificaciones del programa.

Recordar: El diseño de bajo nivel también se conoce como diseño a nivel de objeto o micro nivel o diseño detallado .

Diagrama de clases en LLD

En este diagrama básicamente enumeramos todas las entidades que pueden formar parte de los componentes. Los diagramas de clases se crean a medida que al desarrollador le resulta más fácil convertirlos en código.

Por ejemplo:

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

¿En qué se diferencia LLD de HLD?

Como se estudió, Diseño de alto nivel o DAN es un diseño general de sistema en el que hacemos concesiones entre diferentes marcos, componentes y diferentes bases de datos y elegimos la mejor teniendo en cuenta las necesidades del negocio y cómo debería funcionar el sistema, tanto en términos de aspectos funcionales como no funcionales. Aquí definimos los componentes y cómo estos componentes se comunicarán entre sí. Por lo tanto, aquí nos molestan las cosas genéricas de la siguiente manera y no nos preocupa el código.

1. Selección de componentes, plataformas y diferentes herramientas.
2. Diseño de base de datos.
3. Breve descripción de las relaciones entre servicios y módulos.

¿Cómo formar LLD a partir de HLD?

Como se estudió anteriormente, la entrada para enmarcar el diseño de bajo nivel (LLD) es HLD. Aquí en LLD, nos encargamos de cómo se verán nuestros componentes, la estructura que poseen las diferentes entidades y cómo las diferentes entidades tendrán su responsabilidad (operaciones respaldadas). Para esta conversión utilizamos Diagramas del lenguaje de modelado unificado (UML) . Añadiendo a estos diagramas utilizamos Principios de Ups y Principios SÓLIDOS mientras diseña. Por lo tanto, utilizando estos 3 paradigmas podemos convertir cualquier HLD a LLD para implementarlo.

Hoja de ruta hacia el diseño de bajo nivel

Para unir los conceptos de LLD con el código real, comprendamos cómo diseñar cualquier diagrama de bajo nivel, comprendamos los pasos:

1. Principios orientados a objetos

Los requisitos del usuario se procesan utilizando conceptos de programación OOPS. Por lo tanto, se recomienda tener un buen conocimiento de los conceptos de OOPS antes de seguir adelante en el diseño de cualquier sistema de bajo nivel. Concepto de programación orientada a objetos. Se deben tener 4 pilares para comenzar a aprender diseño de bajo nivel y el programador debe estar muy versado en estos 4 pilares, a saber, los siguientes:

1. Herencia
2. encapsulación
3. polimorfismo
4. abstracción

Dentro del polimorfismo, debemos ser claros con el polimorfismo en tiempo de compilación y en tiempo de ejecución. Los programadores deben tener absolutamente claro los conceptos de OOPS para profundizar en las clases y los objetos porque OOPS es la base sobre la que se basa el nivel bajo en cualquier sistema. Tener éxito en el diseño de bajo nivel es 'extremadamente subjetivo' porque tenemos que utilizar estos conceptos de manera óptima mientras codificamos para construir un sistema de bajo nivel mediante la implementación de entidades de software de codificación (clases, funciones, módulos, etc.)

búsqueda binaria

2. Proceso de análisis y diseño.

Es una fase de análisis, que es nuestro primer paso en el que transformamos problemas del mundo real en problemas del mundo de objetos utilizando conceptos de OOPS y principios SÓLIDOS.

3. Patrones de diseño

Ahora la implementación de nuestro problema orientado a objetos anterior se lleva a cabo con la ayuda de patrones de diseño. Los patrones de diseño son soluciones reutilizables a problemas comunes encontrados en el diseño de software. Proporcionan un enfoque estructurado para el diseño al capturar las mejores prácticas y soluciones probadas, lo que facilita el desarrollo de software escalable, mantenible y eficiente. Los patrones de diseño ayudan a agilizar el proceso de desarrollo, promover la reutilización del código y mejorar la calidad general de los sistemas de software.

Cada patrón describe un problema que ocurre una y otra vez en el entorno y sus soluciones se pueden aplicar repetidamente sin redundancia.

¿Por qué son necesarios patrones de diseño?

Estos problemas han ocurrido una y otra vez, de acuerdo con lo cual se han presentado estas soluciones. Estos problemas son afrontados y resueltos por diseñadores expertos en el mundo de la programación y las soluciones son robustas en el tiempo ahorrando mucho tiempo y energía. De ahí que los problemas complejos y clásicos del mundo del software se resuelvan con soluciones probadas y comprobadas.

Consejo: Se recomienda encarecidamente tener una buena comprensión de los patrones de diseño comunes para tener un buen dominio del diseño de bajo nivel.

Diferentes tipos de patrones de diseño

Existen muchos tipos de patrones de diseño, analicemos 4 tipos de patrones de diseño que se utilizan ampliamente a nivel mundial:

• Patrón de diseño de fábrica
• Patrón abstracto de fábrica
• Patrón singleton
• Patrón de observador

También se recomienda estudiar los 5 patrones de diseño siguientes, ya que son menos necesarios, pero se recomienda aprenderlos para obtener una comprensión básica de los patrones de diseño.

• Patrón de constructor
• Patrón de cadena de responsabilidad
• Patrón de adaptador
• Patrón de fachada
• Patrón de peso mosca

4. diagrama UML

Son 2 tipos de Diagramas UML:

1. Diagrama UML estructural: Este tipo de diagramas básicamente definen cómo se estructurarán las diferentes entidades y objetos y definen la relación entre ellos. Son útiles para representar cómo aparecerán los componentes con respecto a la estructura.
2. Diagrama UML de comportamiento: Este tipo de diagramas básicamente define cuáles son las diferentes operaciones que soporta. Aquí diferentes UML de comportamiento muestran diferentes comportamientos de

Consejo: Los diagramas UML importantes que los desarrolladores utilizan con frecuencia son los siguientes:

• Diagrama de clase de Diagrama UML estructural
• Secuencia , Caso de uso y Actividad del diagrama UML de comportamiento.

5. Principios SÓLIDOS

Estos son conjuntos de 5 principios (reglas) que se siguen estrictamente según los requisitos del sistema o los requisitos para un diseño óptimo.

Para escribir código escalable, flexible, mantenible y reutilizable:

1. Principio de responsabilidad única (SRP)
2. Principio abierto-cerrado (OCP)
3. Principio de sustitución de Liskov (LSP)
4. Principio de segregación de interfaz (ISP)
5. Principio de inversión de dependencia (DIP)

Es importante tener en cuenta que los principios SOLID son sólo pautas y no reglas estrictas a seguir. La clave es lograr un equilibrio entre adherirse a estos principios y considerar las necesidades y limitaciones específicas de su negocio.