Andrey Kopylov , nuestro director técnico, nos dice qué enfoque utiliza el equipo de desarrollo web de AREALIDEA para diseñar la arquitectura de la aplicación, y qué es KISS Architecture, su propio desarrollo, es tan bueno.
Existen muchos enfoques para diseñar una arquitectura de aplicación. MVC, DDD, Clean Architecture y muchos otros.
MVC es muy adecuado para aplicaciones pequeñas. Cuando intenta escalar, MVC se convierte en la arquitectura más común en el mundo de TI: Big Lump of Dirt .
DDD es una gran arquitectura, pero nadie la entiende. A menos que el creador mismo y un par de arquitectos. El propósito de la arquitectura es hacerla comprensible para todos los desarrolladores.
Clean Architecture es una gran arquitectura, pero su implementación completa tiene sentido para grandes aplicaciones. Para pequeños y medianos, me pareció demasiado complicado.
Las tendencias actuales, la transición a servicios y microservicios, en este contexto, Clean Architecture se está volviendo demasiado pesado.
Parecería entonces, tomemos MVC para microservicio y paremos en esto. Pero no, esa bicicleta no nos conviene.
Componentes
La bicicleta para proyectos en nuestra agencia se ensambla a partir de repuestos de diferentes enfoques arquitectónicos.
Estos son los componentes que necesita para crear una estructura comprensible y conveniente:
- Enrutadores
- Controladores
- Vistas
- Servicios
- Modelos
Capas
Enrutador
El enrutador es responsable de las solicitudes de enrutamiento. El tamaño del enrutador y su número indican indirectamente el tamaño de su aplicación. Para una aplicación monolítica grande, puede haber más de una capa de enrutadores.
El enrutador está presente en cualquier arquitectura, pero a menudo de manera implícita. Y dado que lo obvio es mejor que lo implícito, vale la pena sacarlo para que sea una parte integral de la arquitectura.
Controlador
El controlador es una capa entre el enrutador y los servicios. No debe haber lógica empresarial en el controlador.
Cada controlador controla solo una entidad. Si necesita más entidades, entonces necesita agregar otro controlador.
El número y el tamaño de los controladores indican indirectamente el tamaño de su aplicación. La capa vertical debajo del controlador se puede separar en un microservicio separado.
Vistas
La vista está en una capa con el controlador, es responsable de la visualización final de los datos. El controlador después de recibir datos del servicio transfiere los datos a la Vista y devuelve la Vista para su visualización.
En el caso extremo, View es JSON, XML y formatos similares.
Servicios
Solo un Servicio puede contener lógica empresarial. Un servicio generalmente se refiere a un solo modelo. Un servicio puede llamar a otro servicio.
La capa de servicio se divide en Comandos y Consultas (comandos y consultas). Este es el enfoque estándar para CQRS .
Un servicio realiza solo una función. Puede haber cualquier número de funciones privadas y solo una pública. El nombre del servicio comienza con un verbo. Ejemplos: GetUsers, GetPostById, UpdateUser, PublishPost. Es el nombre del servicio que sugiere la separación correcta de la funcionalidad.
En Consultas ponemos servicios que no modifican la base de datos. La consulta contiene una función de obtención pública. En Comandos ponemos servicios que cambian la base de datos. El comando contiene una función de ejecución pública.
Modelos
El modelo contiene solo la lógica más simple asociada con la lectura y el almacenamiento de datos. Además, estas manipulaciones pueden no estar relacionadas con la base de datos.
Si el modelo funciona con una base de datos, un modelo sirve solo una o varias tablas.
Recetas
Microservicio
Un microservicio, en mi opinión, debe administrar solo una entidad. Por lo tanto, la arquitectura para el microservicio más simple se verá así:
- un enrutador;
- un controlador
- múltiples vistas;
- varios servicios;
- Un modelo.
Servicio
El servicio es una mini aplicación. Contiene:
- un enrutador;
- varios controladores;
- múltiples vistas;
- varios servicios;
- Varios modelos
Monolito
Monolith es una gran aplicación. Nadie ama los monolitos por su monstruosidad. Un monolito está justificado si sigues el primer enfoque del monolito. En este estado, su aplicación puede permanecer durante bastante tiempo.
El monolito contiene:
- un SuperRouter
- varios enrutadores ordinarios;
- muchos controladores;
- muchas vistas, muchos servicios;
- muchos modelos
Comienza a parecer un poco aterrador. Aquí puede ver claramente la separación vertical adicional de las capas. Esto permite que la aplicación permanezca aún administrada y mantenida. Aserrar un monolito en partes se convierte en una tarea puramente mecánica.
Para preservar la armonía de la arquitectura necesita:
- Agregue un enrutador de nivel superior que resolverá las rutas globales: SuperRouter.
- Distribuir archivos en una estructura por módulo. Es decir, de acuerdo con el corte futuro en servicios individuales.
Prueba
Dentro del marco de la arquitectura en consideración, solo los servicios están sujetos a pruebas rigurosas, solo la lógica de negocios está integrada en ellos. Y solo necesitas mojarte Modelos.
Si desea probar algo distinto de los servicios, entonces probablemente el lugar para la lógica se elija incorrectamente.
Conclusión
En mi opinión, KISS Architecture es adecuado para el 80% de los proyectos y proporciona una evolución fluida del proyecto.
Este enfoque arquitectónico será claro para todos los desarrolladores y, para su aplicación en la práctica, no es necesario leer libros gruesos sobre DDD.