Este será un relato sobre la impresión que me dejó el libro, así como la discusión de algunos conceptos y conocimientos que, gracias a esta obra, se han aprendido.
Arquitectura
¿Puedes, al leer esta publicación, dar una respuesta clara a la pregunta de qué es arquitectura? ¿Qué es arquitectura en el contexto de la programación y el diseño? ¿Qué papel juega? Hay bastante confusión en torno a este término. Parece que todo está claro, pero resulta abstracto y sin precisión. Martin sostiene, y yo estoy de acuerdo con él, que una aplicación tiene dos componentes:
- Comportamiento (behavior) — las funciones y tareas que un programa (componente, servicio) realiza.
- Arquitectura — este término se refiere en gran medida al cambio de la aplicación.
Pero incluso si una aplicación hace muy bien la tarea que debe cumplir, eso no significa que tenga una buena arquitectura. La arquitectura no se trata del comportamiento de la aplicación. La arquitectura se trata de la facilidad de modificación, la arquitectura se refiere a la facilidad de despliegue, la arquitectura es sobre la independencia en el desarrollo. La arquitectura es sobre la velocidad con la que un nuevo miembro del equipo comprende el sistema.
Y así es como construir esta arquitectura, cómo liberarse del dolor de cabeza con pequeños cambios en los requisitos de PM o de un stakeholder: de esto trata el libro.
Sobre los autores
Antes de hablar de este libro, quiero contar un poco sobre mí.
Actualmente soy un desarrollador Strong Junior, especializado en el desarrollo de servicios a través de ASP .NET CORE.
He estado trabajando un año en una 'galería', y parece que me estoy manejando poco a poco.
He leído este libro ya dos veces, y recomiendo su lectura a todos:
- desarrolladores de sistemas embebidos;
- desarrolladores front-end;
- desarrolladores back-end;
- e incluso a DevOps.
En general, a todos los que de alguna manera están involucrados en el desarrollo de software, me refiero a los que están directamente en la creación de diferentes sistemas, y no incluyo a los Sales y PM, aunque sería útil saber por qué un Dev puede gastar el doble de tiempo en una tarea, les aconsejo leer este libro.
Y ahora intentaré argumentar por qué pienso así.
Un poco sobre el autor de este libro (porque para mí, la autoridad del autor juega un papel importante). Creo que me entenderás, aunque esto no siempre sea correcto, pero si alguien con autoridad en el campo te dice algo, muestras mucho más confianza en lo que dice. Por ejemplo, creo que confiarás más en el diagnóstico que te da un médico que en el de alguna persona del público (que ha buscado los síntomas en Google).
Robert Martin, también conocido como Uncle Bob, trabaja en el campo de la programación, en diferentes sistemas (desde servicios web hasta sistemas embebidos), desde 1970. Es consultor técnico y arquitecto, ha escrito para diversas revistas técnicas, es un programador muy experimentado y una persona que ha jugado un papel fundamental en la creación de los conocidos principios SOLID (se puede decir que es el creador). También quiero agregar que mi líder de equipo, con más de 15 años de experiencia, me recomendó este libro.
Sobre el libro
Dependencias
Antes de leer el libro, leí varios artículos en Habr donde se mencionaba la palabra 'dependencia'. ¿Qué es esto, quién depende de quién, qué significa exactamente 'depender', y cómo puede alguna clase depender de otra?
Y a medida que leía el libro, comprendí dos cosas:
La dependencia es un término que significa que alguna clase (componente, servicio) conoce a alguna otra clase (componente, servicio), y este conocimiento, a nivel de código, se identifica (ahora los programadores de Java, C# y C lo entenderán) mediante una importación específica de namespace. En otras palabras: tienes la clase A con el namespace Default.Classes y la clase B Another.Classes. Entonces, si en el código fuente de la clase A aparece using Another.Classes; — significa que la clase A depende de la clase B.
Para entender en el esquema dónde está la clase dependiente y dónde no, observa la dirección de la flecha: en 1) la flecha señalará desde la clase A hacia la clase B. Esto significa que la clase B es más independiente que la clase A. Y los cambios en la clase A no causarán ningún 'daño' a la clase B.
SOLID
Una de las principales razones que me llevaron a leer este libro fue la explicación de los principios SOLID desde la fuente original, porque el tío Bob desarrolló estos principios y se puede decir que gracias a él escuchamos este nombre: SOLID.
Para aquellos que no están al tanto, estos principios indican y aconsejan diseñar sus aplicaciones de acuerdo con 5 reglas:
S — SRP (Principio de Responsabilidad Única)
O — OCP (Principio Abierto-Cerrado)
L — LSP (Principio de Sustitución de Liskov)
I — ISP (Principio de Segregación de Interfaces)
D — DIP (Principio de Inversión de Dependencias)
Todos estos principios pueden aplicarse a nivel de clases y objetos, a nivel de módulos y componentes, y a nivel de capas (servicios).
Si crees que el Principio de Responsabilidad Única se refiere a que una clase o módulo debe hacer solo una cosa, necesitas leer al menos el capítulo sobre SOLID. Porque esa definición dada anteriormente es una consecuencia, pero no es la definición del principio en sí.
Sobre la Inversión de Dependencias
Quiero poner especial atención en la explicación del Principio de Inversión de Dependencias (el que corresponde a D de SOLID). A medida que leía el libro, entendí que no es solo un principio, es también un mecanismo y herramienta, con la cual puedes cambiar la dirección de tus dependencias y hacer, por ejemplo, que la lógica empresarial (DOMINIO) sea independiente de los detalles de implementación de la capa de acceso a datos (DAL).
Aunque el propio principio, junto con los demás en SOLID, significa un poco diferente que un mecanismo, el mecanismo se utiliza a lo largo del libro, y es uno de los métodos principales para invertir y cambiar la dirección de tus dependencias, que, por cierto, se utiliza en DDD.
Sobre la toma de decisiones arquitectónicas
A menudo en el libro se menciona el principio sobre la toma de decisiones arquitectónicas importantes: sobre qué base de datos utilizar, qué marco emplear, qué biblioteca conectar, qué utilizar como motor de búsqueda, etc.
Así que, el autor considera: deberías tomar lo MENOS posible este tipo de decisiones. Porque los requisitos pueden cambiar, las limitaciones de rendimiento también, y el componente conductual tiende a cambiar. En el proceso de desarrollo, alguna decisión puede parecer menos efectiva que otra, menos conveniente que otra. Y la fuerza de tu arquitectura determinará cuán rápido y sin dolor puedes reemplazar una tecnología por otra (sobre esto, por cierto, insiste el OCP).
Por ejemplo, de repente, decides utilizar MongoDB en lugar de PostgreSQL, o incluso archivos, o usar datos simulados, operaciones que se realizarán en memoria. Y bajo ciertas condiciones, esto puede obligar a reescribir casi toda la lógica.
Para evitar que se presenten tales situaciones, podemos utilizar ciertos mecanismos que alejen al máximo el momento de la toma de decisiones. Uno de estos mecanismos es la abstracción.
Referencias a DDD
DDD — Diseño Guiado por el Dominio — es un enfoque para el desarrollo de servicios con lógica de negocio compleja y crítica a cambios, que está orientado a lograr una comprensión máxima por parte de los responsables del proyecto (PMs, gerentes de ventas, etc.) junto a los desarrolladores. Es decir, que entre todos los miembros del proyecto haya un lenguaje ubicuo, y cada uno pueda entender al otro, y que todos piensen en un mismo dominio con las mismas reglas de negocios.
Si eres un defensor de DDD, o deseas serlo, o no comprendes bien el tema pero quieres entenderlo — este libro es una lectura obligada, especialmente la segunda parte del libro.
Aquí el autor explica la existencia de la Regla de Dependencia, y por qué, al seguirla, construirás una arquitectura de aplicación adecuada. Por qué las dependencias deben dirigirse hacia los componentes de alta política. nombre de dominio (Los componentes de alta política) deben ser independientes de la infraestructura y cómo esto te facilitará el despliegue y el desarrollo.
Abstracción
El tío Rob también relata cómo los detalles de implementación pueden perjudicar tu sistema, y no permitirle evolucionar sin dolor en el futuro.
¡Recuerda!
La BD es un detalle de implementación
Los clientes (Web, Móvil, etc.) son detalles de implementación
Los frameworks son un detalle de implementación
Es necesario abstraerse al máximo de todo esto y no depender, utilizando el mencionado Inversión de Dependencias con interfaces y abstracciones, la Regla de Dependencia y otros mecanismos.
Métodos para construir módulos
Esta sección me gustó especialmente, como desarrollador de servicios en ASP .NET CORE. Aquí se discuten metodologías para construir una arquitectura única de servicio a partir de componentes existentes.
Robert describió 4 posibles esquemas de separación de capas.
Dejó claro por qué el mecanismo de arquitectura de tres capas tan frecuentemente utilizado: UI (controladores), Servicios (Dominio), DAL (Base de Datos) — es bastante malo en comparación con otros. He visto no muchos proyectos, pero en cada microservicio por ejemplo, en el backend, se utiliza precisamente la arquitectura de tres capas.
Además, a menudo se utiliza la arquitectura de un componente por servicio. En general, ambas son buenas, pero tiene muchas desventajas en comparación con, por ejemplo, cómo se construye la arquitectura usando DDD, especialmente en servicios críticos al cambio y complejos.
En general, hemos llegado al final de esta reseña del libro. Me gustó mucho el libro, no me arrepiento de haberlo leído, gracias al autor. Ustedes, queridos lectores, gracias por su atención, no sean demasiado duros — esta publicación se basa en mis impresiones sobre el libro y mi entusiasmo personal.
Fuente: habr.com
