Esta será una historia sobre la impresión del libro, así como algunos conceptos y conocimientos que, gracias a este libro, fueron estudiados
Arquitectura
¿Puede usted, leyendo esta publicación, dar una respuesta clara a la pregunta, qué es la arquitectura? ¿Qué es la arquitectura en el contexto de la programación y el diseño? ¿Qué papel juega ella? Hay muchas ambigüedades en este término. Y todo parece estar claro, pero de alguna manera abstracto, y sin precisión. Martin cree, y estoy de acuerdo con él, que la aplicación tiene dos componentes:
- Comportamiento (comportamiento): funciones y tareas que realiza el programa (componente, servicio).
- Arquitectura: este término trata más sobre el cambio de aplicaciones.
Pero incluso si la aplicación realiza muy bien la tarea que debería realizar, esto no significa en absoluto que tenga una buena arquitectura. La arquitectura no se trata del comportamiento de la aplicación. La arquitectura se trata de la facilidad de cambio, la arquitectura se trata de la facilidad de implementación, la arquitectura se trata de la independencia del desarrollo. La arquitectura trata sobre la velocidad con la que la comprensión llega a una nueva persona en un equipo
Y aquí está cómo construir esta arquitectura, cómo deshacerse de un dolor de cabeza con un pequeño cambio en los requisitos de PM o de una parte interesada: esto es lo que el libro contará
Sobre los autores
Antes de decir algo sobre este libro, quiero decir un poco sobre mí.
Por el momento, soy un desarrollador junior fuerte especializado en el desarrollo de servicios a través de ASP .NET CORE.
Llevo un año trabajando en una "galería" y parece que estoy haciendo un poco
Ya leí este libro 2 veces, y lo recomiendo a todos para que lo lean:
- desarrolladores de sistemas embebidos;
- motociclistas delanteros;
- avaladores;
- e incluso devopsam.
En general, para cualquiera que esté al menos de alguna manera conectado con el desarrollo del PP, me refiero al desarrollo directo de los diferentes Saylov y PM que no tenemos en cuenta aquí (aunque también sería útil saber por qué una criada pasa 2 veces más tiempo en una tarea), le aconsejo que lea este libro
Y ahora trataré de discutir por qué lo creo
Un poco sobre el autor de este libro (porque para mí la autoridad del escritor juega un papel importante). Creo que me entenderá, aunque esto no siempre es correcto, pero si una persona autorizada en la esfera le dice algo, usted muestra mucha más confianza en lo que dijo. Por ejemplo, creo que preferiría creer en el diagnóstico que le hace el médico que en una persona de la multitud (google los síntomas)
Robert Martin, también conocido como Ankle Bob (tío Bob), ha estado trabajando en el campo de la programación y desde varios sistemas (desde servicios web hasta sistemas integrados), desde 1970. Es consultor técnico y arquitecto, escribió en varias revistas técnicas, es un programador muy experimentado y una persona que desempeñó uno de los roles clave en la creación de los principios SOLID bien conocidos (se puede decir el creador). Además, quiero agregar que mi líder de equipo con más de 15 años de experiencia me aconsejó en este libro
Sobre el libro
Dependencias
Antes de leer el libro, leí muchos artículos sobre el mismo Habré, donde apareció una palabra como "dependencia". ¿Qué es, quién depende de quién, qué significa exactamente "depender" y cómo puede una clase depender de alguien?
Y mientras leía el libro, aprendí dos puntos:
Dependencia es un término que significa que alguna clase (componente, servicio) sabe acerca de otra clase (componente, servicio), y este conocimiento a nivel de código está determinado (ahora los javists, más agudos, la gente me entenderá) por una determinada importación de espacio de nombres . En otras palabras: tiene una clase A con un espacio de nombres Default.Classes y una clase B Another.Classes. Entonces, si el código de clase A aparece usando Another.Classes; - esto significa que la clase A depende de la clase B.
Para comprender según el esquema dónde está la clase dependiente y dónde no, mire la dirección de la flecha: 1) la flecha apuntará desde la clase A en la dirección de la clase B. Esto significa que la clase B es más independiente que la clase A. Y los cambios en la clase A , sin "daños" a la clase B
SÓLIDO
Una de las principales razones para leer este libro fue la explicación de los principios SÓLIDOS de la fuente original, porque el Tío Rob desarrolló estos principios, y podemos decir que gracias a él escuchamos este nombre: SÓLIDO.
Para aquellos que no están al tanto, se dicen y se recomiendan estos principios para 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 interfaz)
D - DIP (principio de inversión de dependencia)
Todos estos principios se pueden aplicar a nivel de clases y objetos, a nivel de módulos y componentes, y a nivel de rieles (servicios).
Si cree que el principio de responsabilidad individual se trata del hecho de que la clase o el módulo deberían hacer una sola cosa, entonces definitivamente debería leer al menos el capítulo sobre Solid. Porque la definición dada anteriormente es una consecuencia, pero no la definición del principio mismo
Acerca de la inversión de dependencia
Quiero prestar especial atención a la explicación del Principio de Inversión de Dependencia (el que D es de SÓLIDO). Mientras leía el libro, entendí que esto no es solo un principio, también es un mecanismo y una herramienta con la que puede cambiar la dirección de sus dependencias y hacer, por ejemplo, la lógica de negocios (DOMINIO) independiente de los detalles de la implementación de la capa de acceso a datos (DAL'a)
Aunque el principio en sí, junto con los demás en SOLID, significa algo más que el mecanismo, el mecanismo en sí se usa en todo el libro, y este es uno de los principales métodos para invertir y cambiar la dirección de sus dependencias, que por cierto se usa con DDD
Sobre tomar decisiones arquitectónicas
Muy a menudo, el libro mencionará el principio de tomar decisiones arquitectónicas importantes: qué base de datos usar, qué marco usar, qué biblioteca conectar, qué usar como motor de búsqueda, etc.
Entonces, el autor cree: debe ASAP antes de tomar este tipo de decisión. Debido a que los requisitos pueden cambiar, las restricciones de desempeño también, el componente de comportamiento en sí mismo tiende a cambiar. Durante el proceso de desarrollo, alguna solución puede parecer menos efectiva que otra, menos conveniente que otra. Y la fortaleza de su arquitectura determinará qué tan rápido y sin dolor puede reemplazar una tecnología por otra (OCP dice esto por cierto).
Por ejemplo, de repente, decide usar MongoDb en lugar de Postgresql, o archivos en general, o usar datos simulados, las operaciones con las que se realizarán en la memoria. Y bajo ciertas condiciones, esto puede hacer posible reescribir casi toda la lógica.
Para evitar tales situaciones, podemos usar algunos mecanismos que impulsarán el tiempo de toma de decisiones lo más posible. Uno de estos mecanismos es la abstracción.
Referencias DDD
DDD: diseño impulsado por dominio: un enfoque para desarrollar servicios con una lógica empresarial compleja, fundamental para los cambios, cuyo objetivo es maximizar la comprensión de los puestos de gestión de proyectos (PM, gerentes de ventas, etc.), con remeros. Es decir, que habría un lenguaje omnipresente entre todos los miembros del proyecto, y todos podrían entender al otro, y que todos piensen en el mismo dominio con las mismas reglas comerciales.
Si eres partidario de DDD, o quieres ser uno, o no entiendes algo sobre esto, pero quieres entender, el libro es de lectura obligatoria, especialmente la segunda parte del libro.
Aquí el autor explica la existencia de la Regla de dependencia y por qué, a continuación, construirá la arquitectura de aplicación correcta. Por qué las dependencias deberían seguir hacia los componentes de Alta Política, por qué el dominio (componente de Alta Política) debería ser independiente de la infraestructura y cómo simplificará la implementación y el desarrollo para usted
Abstracción
El tío Rob también habla sobre cómo los detalles de implementación pueden dañar su sistema y evitar que evolucione sin problemas en el futuro.
Recuerda!
DB es un detalle de implementación
Clientes (web, móvil, etc.): detalles de implementación
Los marcos son un detalle de implementación.
Es necesario abstraer tanto como sea posible y no depender de él, utilizando la Inversión de dependencia descrita anteriormente con interfaces y abstracciones, Regla de dependencia y otros mecanismos
Métodos para construir módulos
Me gustó especialmente esta sección como desarrollador de servicios en ASP .NET CORE. Describe las metodologías para construir una arquitectura de servicio unificada a partir de componentes listos para usar.
Robert describió 4 posibles esquemas de separación de capas.
Dejó en claro por qué el mecanismo tan utilizado de la arquitectura de 3 capas: UI (controladores), Servicios (Dominio), DAL (Base de datos), es lo suficientemente malo en comparación con otros. No he visto muchos proyectos, pero en cada uno, por ejemplo, microservicio, en el back-end, utiliza una arquitectura de tres capas.
Además, con bastante frecuencia, se utiliza la arquitectura de un componente y un servicio. En general, ambos son buenos, pero tiene muchas desventajas, en comparación, por ejemplo, cómo se construye la arquitectura usando DDD, especialmente cuando es crítico para el cambio, y servicios complejos.
En general, esta revisión del libro ha llegado a su fin. Realmente me gustó el libro en sí, no me arrepiento de lo que leí, gracias al autor. Gracias por su atención, queridos lectores, no juzguen estrictamente: esta publicación se basa en la impresión del libro y en mi entusiasmo personal.
ACTUALIZACIÓN 1.0
Durante las discusiones, se puede entender que el cambio de almacenamiento SUDDEN y EASY no será fácil, de una forma u otra. En algunos casos, incluso una abstracción y encapsulación de acceso a la tienda muy dolorosa y, sin embargo, muy dudosa, es dudoso qué empeorará la situación, sino que mejorará un poco, al menos debido a la independencia del componente variable de los demás.