Imagen del blog tomaszjaniak
Muéstranos tu Arquitectura
Da la casualidad de que ha estado trabajando en un proyecto durante un par de años y ahora mismo está sentado hasta los codos en el código, las pruebas se están quemando, el enfriador de la computadora portátil está haciendo ruido, tratando de enfriar el calor del procesador sobrecalentado por el compilador, solo unas pocas horas más, y la refactorización habrá terminado. Y luego necesitamos dejar todo urgentemente y dibujar la Arquitectura del proyecto. Se planea un gran cliente y, para cerrar el trato, es necesario someterse a una auditoría. Y en este caso, no hay ningún lugar sin diagramas arquitectónicos. Entonces, ¿qué pasa si el proyecto aún es pequeño y una docena de sus desarrolladores en el trabajo real no necesita ninguna Arquitectura allí? Aquí está el código: todo está claro. Pero no hay salida. Es necesario, entonces es necesario.
Si sabes cómo funciona todo, la arquitectura de cualquier producto se puede dibujar en una hora. Y esto suele ser suficiente para una auditoría. Después de todo, el objetivo de la auditoría no es que los externos comprendan realmente la arquitectura de su producto. El objetivo de la pregunta es determinar si los propios desarrolladores de productos comprenden lo que están haciendo. Y si habla con la suficiente confianza y responde a las preguntas sin dudarlo, todo saldrá bien. Sin embargo, cuando esta historia termine, en algún lugar de las profundidades se posará un gusano, lo que agudizará la pregunta: pero aún así, ¿qué tipo de Arquitectura tiene realmente el producto? Después de todo, si preguntan, probablemente otros tengan Arquitectura. Y si no lo tenemos, claramente es un lío. Hay un gran deseo de hacer todo bien para poder ser responsable de la Arquitectura la próxima vez como debe ser.
¿Cómo lo haces bien? Necesita dibujar diagramas, describir características en documentos y luego mantener todo esto actualizado. Entonces será Arquitectura. Pero, habiendo presentado la cantidad de trabajo, rápidamente llegamos a comprender que todo esto no vale la pena el tiempo invertido. Aquí está el código: todo está claro. Y si viene otro cliente, en otra hora será posible dibujar un nuevo diagrama.
Y después de unos años, puede encontrarse en la situación opuesta, y los documentos que describirán la arquitectura de otro producto no serán mejores. Por supuesto, es útil saber que otros también tienen una arquitectura muy mala. Pero cuando el tamaño del proyecto comienza a medirse en millones de líneas de código y el número de desarrolladores en cientos, la cuestión de la necesidad de una Arquitectura sigue siendo significativa.
Aquí, en el marco del flujo de trabajo, comienzan a aparecer varios diagramas arquitectónicos, se comienzan a escribir Propuestas Arquitectónicas sobre funcionalidades, todo esto se discute, revisa, valida, aprueba y, por supuesto, queda desactualizado incluso antes de que finalicen estos procesos. No es necesario decir que dichos documentos reflejan la estructura real del código de la aplicación. Y cuando se trata de implementación, sucede que los desarrolladores no leen estos documentos en absoluto. O se está implementando algo completamente diferente de lo que se escribió. Alguien malinterpretó a alguien, o era urgente hacerlo, y no había tiempo para discutir.
Quizás todo sea como debería ser. ¿Quizás la Arquitectura sea la Burocracia en torno a los documentos especulativos, divorciada de la realidad? Pero la intuición nos dice que, después de todo, no. Entonces, ¿qué es "Arquitectura"?
La arquitectura es ...
¿Qué sucede si hace la pregunta "¿Qué es la arquitectura?" diez desarrolladores profesionales? Si no indagas en Wikipedia, ¿te darán la misma respuesta?
La arquitectura es tanto un conjunto de decisiones importantes, como la estructura de elementos y sus interfaces, y un sistema de disposiciones, reglas y acuerdos, y enfoques formados que mantienen el orden y las soluciones a los problemas globales y la descomposición con la interacción, y una descripción de alto nivel del sistema y su ciclo de vida. partes y patrones de estructura y comportamiento, y lo que es difícil o costoso de cambiar o eliminar, y decisiones fundamentales y compensaciones, y mucho más.
La arquitectura es también la forma en que una aplicación cumple su propósito.
La API es una Arquitectura, un esquema de datos también es una Arquitectura y una estructura de módulos y servicios. Existe una arquitectura de escalado de aplicaciones, una arquitectura de confiabilidad de aplicaciones, una arquitectura de interacción de componentes y una arquitectura de seguridad. Y, por supuesto, cada característica tiene su propia Arquitectura. Y todo esto junto es también Arquitectura.
Todo esto puede considerarse una respuesta a la pregunta "¿Qué es la Arquitectura?" - quizás sí. Todo parece estar correcto, todo parece estar claro. Pero, ¿es esta respuesta prácticamente útil, algo que se puede utilizar en un flujo de trabajo real? Realmente no.
¿Cómo saber si una decisión es importante o fundamental? ¿Qué son los desafíos globales? ¿Qué significa caro o barato? ¿Cómo estima la complejidad? ¿Dónde está la frontera entre el nivel alto y el nivel bajo? ¿Qué es el orden? ¿Cuál es el propósito del sistema?
Todas estas son preguntas que también puede intentar responder. Formular definiciones, explicar con ejemplos, en el peor de los casos, organizar el proceso de toma de decisiones. Pero seguirá siendo algo controvertido, algo intuitivo, dependiendo de la percepción personal y entendido por cada uno un poco a su manera. Esto significa que siempre habrá conflictos basados en el hecho de que diferentes personas interpretan la misma situación de manera radicalmente diferente. Los desarrolladores se quejarán de que los arquitectos están manipulando los detalles de implementación, los arquitectos de que los desarrolladores están rompiendo la Arquitectura. Si no hay un límite claro, los conflictos son inevitables.
Probablemente todos tengan una comprensión general de lo que es la arquitectura. Pero es difícil nombrar una definición única, formalmente verificada y matemáticamente precisa.
Por otro lado, si preguntas "¿Qué es la realización?" - Es probable que la respuesta no sea ambigua: "¡Aquí hay un enlace al depósito de código!" Y no puedes discutir con eso. Y no hay dudas ni ambigüedades en la interpretación de esta respuesta. 1 + 1 = 2, la implementación es código.
Y es muy fácil trabajar con el código. Si desea comprender la implementación, puede abrir el proyecto en el entorno de desarrollo. Si es necesario revisar los cambios en el código, entonces hay ramas en el repositorio. Si es el momento de lanzar una nueva versión de la aplicación, se lanzan las pruebas.
Por supuesto, la estructura del proyecto puede ser confusa, las revisiones son de mala calidad y la cobertura de las pruebas es incompleta. Pero, al menos cuando se trabaja con código, siempre queda claro qué hacer y cuándo hacerlo.
Pero, ¿y si la Arquitectura se expresara en código, al igual que la Implementación?
Muchos lenguajes de programación convencionales se utilizan en el desarrollo moderno. La mayoría de ellos aparecieron hace mucho tiempo o hace mucho tiempo. Y aunque todavía son buenos, se están desactualizando un poco. Estos son lenguajes de tipado débil: JavaScript, Python, PHP, Ruby y lenguajes de tipado fuerte: Java, C / Objective-C / C ++, C #. Están siendo reemplazados por nuevos lenguajes que, en el marco de la misma plataforma, intentan resolver problemas de larga data, rociándolos con azúcar sintáctico, pero sin introducir conceptos fundamentalmente nuevos si miras globalmente: Swift, Kotlin, TypeScript, Go. Todos estos son lenguajes basados en el paradigma orientado a objetos. Además, el enfoque funcional de la programación ha ganado una popularidad madura, que se implementa en los idiomas enumerados y se presenta en idiomas especializados, pero menos popular: Erlang, F #.Los lenguajes que implementan conceptos sustancialmente nuevos también están comenzando a ganar popularidad: Rust, Haskell.
Toda esta diversidad tiene una cosa en común: todos son lenguajes de implementación. Ninguno de estos lenguajes de programación son expresiones de Arquitectura. Pero hay una excepción: SQL.
SQL es el único lenguaje de programación convencional que es declarativo. Se basa en el modelo de álgebra relacional y tiene una especialización limitada: trabajar con datos almacenados. Pero aún así, ¿por qué SQL puede considerarse el lenguaje de la arquitectura?
En primer lugar, SQL da acceso a metainformación sobre el esquema de datos. La base de datos puede obtener fácilmente una lista de tablas, columnas, relaciones, índices, vistas, roles y más. Documentar el esquema de almacenamiento y poder visualizarlo es de gran ayuda para comprender la estructura de su aplicación. Una descripción de esquema de datos es un tipo de descripción de arquitectura de alto nivel.
En segundo lugar, SQL proporciona un lenguaje de consulta de datos que permite al cliente consultar cualquier combinación de datos descritos en el esquema. Si no hubiera un lenguaje de consulta, entonces para cada modelo de datos requerido por el cliente, se tendría que implementar un método de API separado o el cliente se vería obligado a realizar varias llamadas a la API a diferentes partes del esquema de datos y combinar el modelo requerido en su lado. La presencia del lenguaje de consulta permite excluir de la descripción de la implementación de la Arquitectura detalles asociados a la enumeración de métodos API para la obtención de modelos de datos específicos según el esquema general. El lenguaje de consulta excluye los detalles de implementación de la descripción de la Arquitectura.
SQL proporciona tres propiedades clave que son importantes para describir la arquitectura:
- Declaratividad: SQL le permite separar la descripción de la Arquitectura de su Implementación.
- Capacidad de análisis: SQL proporciona acceso a la metainformación del esquema de datos, lo que le permite visualizar, documentar y analizar sus representaciones.
- Corrección: SQL le permite definir las restricciones del modelo de datos, lo que hace posible evitar varias violaciones de la integridad de los datos por parte de la implementación.
Quizás, SQL se puede llamar una herramienta para describir la Arquitectura en términos de almacenamiento de datos, pero claramente no es suficiente para describir la Arquitectura completa de un producto.
Otros medios de describir la arquitectura
El análogo directo de SQL es GraphQL, que también le permite definir el esquema de datos y proporciona acceso a él a través del lenguaje de consulta. Al mismo tiempo, GraphQL se basa en la teoría de grafos, no en un modelo de álgebra relacional. Esto hace posible trabajar con modelos de datos jerárquicos de una manera más natural, a diferencia de SQL, donde trabajar con jerarquías puede ser difícil.
GraphQL a menudo se promociona como una solución de comunicación cliente-servidor, pero esta no es la única área de su uso. De manera similar, a través de GraphQL, puede proporcionar comunicación de servidor a servidor e incluso comunicación de servidor a base. El hecho de que las bases de datos modernas proporcionen solo una interfaz SQL, pero no proporcionen una API conveniente para trabajar con consultas jerárquicas es una omisión ofensiva.
Si SQL es un medio para describir la Arquitectura del esquema de almacenamiento de datos, GraphQL le permite describir la Arquitectura del esquema de datos ya a nivel empresarial, en términos de un área de aplicación específica. En este sentido, GraphQL permite definir la Arquitectura a un nivel superior, más cercano al área de aplicación real del producto.
Los módulos de código y microservicios, junto con sus API y dependencias, también son vehículos para expresar la Arquitectura en términos de estructura y relaciones.
Arquitectura e implementación
Para un proyecto pequeño con una docena de desarrolladores trabajando, a menudo no se requiere una descripción separada de la Arquitectura. Si el código del proyecto está escrito de manera prolija y bien estructurada, esto puede ser suficiente para comprender el panorama general y las direcciones del desarrollo.
A medida que el proyecto crece, aparecen varios documentos que describen tanto su Arquitectura general como los detalles de nuevas piezas y mejoras importantes. Este es un enfoque bastante funcional en el caso de que varias docenas de personas estén trabajando en un proyecto.
Pero para un proyecto bastante grande, cuando hay cientos de desarrolladores, este enfoque comienza a fallar. Hay demasiados documentos y su contenido comienza a diferir cada vez más de la Implementación. Cada vez es más difícil expresar pensamientos de la misma manera para todos. Se organizan mítines para decenas de personas para discutir una variedad de temas privados, mientras que los cambios realmente importantes se pueden implementar sin ninguna discusión. Todo esto lleva a la necesidad de organizar cada vez más procesos, cuando unos tienen que ofrecer algo, otros siguen, otros revisan y otros lo hacen. Burocracia. Como resultado, los desarrolladores están comenzando a escribir más documentos y menos código, y este no es el problema más importante.
Por supuesto, no hay nada de malo en la burocracia como tal. En cualquier trabajo, su organización es importante. El problema es la cantidad de burocracia por unidad de trabajo útil. Si, para hacer Uno, necesita realizar dos mítines más, Tres, Cuatro, Cinco, esto ya no es bueno en ningún lado.
Incluso la simple pregunta de qué cambio puede hacer el propio desarrollador, porque se trata de una Implementación, y sobre qué necesidad de hacer una solicitud de revisión, porque se trata de una Arquitectura, comienza a generar dificultades. Tiene que encontrar una variedad de disparadores arquitectónicos, que si cambia el esquema de datos o toca problemas de criptografía y seguridad, esto debe revisarse arquitectónicamente, y otros temas parecen no serlo, pero esto no es seguro. Todo esto no solo debe ser formulado y explicado a cientos de desarrolladores, sino también para garantizar que se sigan las reglas descritas. Tal proceso fallará constantemente.
Todos estos problemas están relacionados con la falta de una definición clara de la Arquitectura.
Así como cambiar un archivo ".java" en un repositorio indica sin ambigüedad un cambio en la implementación, cambiar un archivo ".architecture" puede indicar un cambio en la arquitectura. Por supuesto, los archivos ".architecture" no existen en la naturaleza. Pero para cada proyecto, puede definir qué aspectos específicos se relacionan con su arquitectura y hacerlo explícito.
Si un cambio en el esquema de datos se considera un cambio en la Arquitectura, entonces los archivos que contienen las migraciones SQL deben pertenecer a la Arquitectura. Si la API también es parte de la Arquitectura, puede definir la API en forma de los mismos archivos swagger y confiar en ellos. Si la estructura de los módulos es Arquitectura, entonces el cambio en la descripción de los módulos es un cambio Arquitectónico. Etc.
No todos los aspectos de la arquitectura pueden expresarse por medios estándar. Cada proyecto tiene sus propios detalles. Por ejemplo, si el producto utiliza un modelo específico de derechos, roles, tipos de suscripciones, complementos, etc., entonces debería pensar en definir la Arquitectura de este aspecto del producto en alguna forma Declarativa adecuada, destacando así la esencia de la Arquitectura a partir de los detalles de implementación. Por supuesto, tales cambios pueden requerir una reelaboración significativa del código. Pero esta es una inversión sustancialmente mejor para definir una arquitectura de producto que tratar de describir su modelo de derechos en un documento.
La representación formal de la Arquitectura en código es posible, y solo esto da una definición clara de lo que es una Arquitectura. Esta vista permite analizar la Arquitectura y generar automáticamente documentación sobre ella, que estará siempre actualizada. Todo lo demás: documentos, esquemas y esquemas hechos a mano - Burocracia.
Una Arquitectura puede tener una expresión formal en código, y solo esto define un límite claro entre Arquitectura e Implementación. Y esa frontera es necesaria.
Enfoques de ingeniería y evolución en arquitectura
Durante el último medio siglo, la industria del desarrollo ha recorrido un largo camino desde los modelos en cascada hasta el desarrollo iterativo. Y ahora parece que la industria ha ido demasiado lejos en este asunto. En algunos lugares, el trabajo de un arquitecto ya no se parece al de un ingeniero o incluso al de un jardinero, y cada vez más comienza a parecerse al trabajo de un trabajador temporal contratado con el único propósito de deshierbar las camas.
Lo que distingue a la ingeniería de la artesanía es la comprensión de las leyes de la naturaleza, las regularidades, sobre cuya base se pueden hacer cálculos y conclusiones, diseñar soluciones y no experimentar. Cualquier carpintero puede hacer un taburete perfectamente aceptable, pero se necesitan conocimientos de ingeniería para que el taburete sea óptimo: ligero, confiable, estable, simple y económico de fabricar. Un enfoque de ingeniería le permite obtener el resultado óptimo de forma rápida y con el mínimo esfuerzo. Desafortunadamente, en el desarrollo de software, no siempre es posible un enfoque de ingeniería.
A menudo, el resultado que se desea lograr está definido de manera muy vaga, muchos factores que afectan significativamente la arquitectura de la solución no están claros o no se conocen en absoluto, y el trabajo de implementación de la solución en sí puede ser más rápido y económico que la elaboración detallada de su Arquitectura. Esta es una de las razones por las que el enfoque iterativo del desarrollo ha ganado tanta popularidad. A veces incluso más allá de toda medida.
En el peor de los casos, el desarrollo de la Arquitectura puede reducirse al hecho de que cada equipo de desarrollo simplemente le da al arquitecto una revisión de una descripción de lo que van a implementar. En tal situación, el trabajo de un arquitecto se reduce a eliminar. ¿Y aquí no lo has olvidado? ¿Ha tenido esto en cuenta? Y aquí está mal. ¿Quieres agregar un índice aquí? Y así iteración tras iteración.
Es necesario quitar las malas hierbas. Pero, ¿cómo será un jardín si solo haces esto? Los macizos de flores se marchitarán a la sombra de los árboles frutales, se alternarán fresas y zanahorias, y todo esto será atravesado por innumerables senderos que desperdician el espacio disponible. Es difícil hablar de Arquitectura aquí.
Para que aparezca la Arquitectura, un arquitecto debe hacer al menos el trabajo de un jardinero. Las bayas y las verduras deben cultivarse por separado: la estructura, y donde la gente va con más frecuencia, deben establecerse caminos: conexiones. Observando los detalles, el arquitecto puede actuar de manera proactiva, organizando y sistematizando las particularidades que surgen en el proceso de Realización en una sola estructura. Al igual que el diseño del paisaje, un arquitecto puede dar forma al curso natural de los eventos, reforzando las tendencias positivas y previniendo las negativas.
Y aquí necesitamos una definición clara de la Arquitectura en el código. Esquemas de datos, estructuras de módulos y servicios, su API y reglas de interacción. Sin definir estas herramientas, el arquitecto se empantanará en una revisión de implementación o esperará ingenuamente que los desarrolladores realmente sigan las reglas descritas en algunos documentos allí, lo que, por supuesto, no sucederá.
Si hay una presentación formal de la Arquitectura y las reglas para sus cambios, esto ya se puede llamar un enfoque evolutivo para el desarrollo de la Arquitectura. Y eso no está mal. ¿Pero deberíamos limitarnos a esto?
Sí, inicialmente los requisitos pueden parecer vagos, los factores pueden parecer vagos y el sistema en sí es tan complejo que es más fácil de hacer que de diseñar. Pero con el tiempo, estas cosas comienzan a aclararse. Con experiencia práctica en el desarrollo de la Arquitectura, los detalles de la organización de su área de aplicación aparecen cada vez más claros. Queda claro que esta solución general se implementa de cinco formas diferentes y que los usuarios sufren esta diversidad. Que algunas cosas están fuera de lugar y deben moverse, mientras que otras ya están desactualizadas y reemplazadas por nuevas soluciones, por lo que deben eliminarse. Y los nuevos desarrollos dejan de parecer tan nuevos, y ya hemos implementado esto y aquello. ¿Recuerdas a qué condujo todo esto? Hagámoslo de inmediato para no tener que rehacerlo más tarde. Después de todo, hacerlo bien de una vez suele ser más rápido de lo necesario.Pero esto es solo si realmente sabe cómo hacerlo bien. Y con la experiencia, esa comprensión a menudo llega.
La buena arquitectura no es algo que haya crecido por sí solo y luego se haya organizado un poco, sino algo holístico, simétrico y orgánico. Es posible un enfoque de ingeniería para el desarrollo de la arquitectura, solo comprender las reglas y los patrones puede llevar algún tiempo.
La definición formal de la Arquitectura de un proyecto en particular no tiene por qué ser estática. Los métodos de API obsoletos se pueden declarar como obsoletos y los que faltan se pueden declarar como no implementados. Las partes significativas del código se pueden marcar para colocarlas en módulos separados. Puede planear dividir la tabla en dos o moverlos a otra base de datos. Etc. La arquitectura se puede cambiar sin cambiar la implementación. La implementación se pondrá al día. Y para ponerse al día más rápido, el proceso se puede automatizar levemente haciendo recordatorios automáticos en los chats de equipo. De la misma manera, los cambios realizados por los desarrolladores en los archivos de arquitectura pueden ir automáticamente al chat del equipo de arquitectura.
Es posible un enfoque de ingeniería para el desarrollo de la Arquitectura.
Al mismo tiempo, no se debe asumir que el trabajo del arquitecto es fundamentalmente mejor o peor que el trabajo del desarrollador. Ella es simplemente diferente. El desarrollador, en primer lugar, trabaja en el estilo Imperativo, mientras que el trabajo del arquitecto es más Declarativo. Sucede que es difícil trabajar la Arquitectura, pero la Implementación es una rutina. También sucede al revés.
Arquitectura y Diseño
Los términos Arquitectura y Diseño a menudo se usan indistintamente. Puede decir: Arquitectura del sistema o Diseño del sistema. En general, está claro de qué se trata. Sin embargo, existen diferencias significativas en estos términos.
El diseño, en primer lugar, significa algo visual, algo que se puede imaginar o ver. Esquemas, diagramas, modelos. El diseño le permite mostrar visualmente la relación entre entidades, trazar cadenas de interacción, ver diferencias estructurales y analogías.
Pero la arquitectura no es solo visual, puede incluir reglas y restricciones, inferencias y cálculos matemáticos. Conceptos mal visualizados.
Por supuesto, ambos son importantes.
Es bueno si los aspectos importantes de la arquitectura se definen explícitamente en el código. Pero esto no es suficiente. Es importante hacer visual la Arquitectura y automatizar los principios inherentes a ella.
Si la Arquitectura incluye un esquema de datos, debe haber una representación visual del mismo. Los módulos tienen dependencias, también necesitan renderizarse. Si hay una API, debe haber documentación relacionada directamente con la estructura de los servicios. Etc. El diseño es una representación visual de la arquitectura.
Si la Arquitectura tiene ciertos principios, por ejemplo, "las aplicaciones cliente solo pueden acceder a ciertos tipos de microservicios, pero no a todos", entonces si existe un modelo de comunicación, se pueden verificar automáticamente. Asimismo, puede controlar los vínculos entre microservicios y bases de datos. Si existen ciertas reglas para el diseño de modelos de datos, las mismas reglas para nombrar tablas, entonces también se pueden verificar automáticamente. En desarrollo se utilizan verificaciones de código automáticas, lo mismo se puede hacer para la Arquitectura. Puede escribir pruebas automáticas en Arquitectura.
Conclusión
El desarrollador moderno tiene una amplia gama de herramientas increíbles disponibles para facilitar su trabajo. Entornos de desarrollo, sistemas de construcción, diversas bibliotecas y marcos, servicios de infraestructura y contenedores. Los desarrolladores no escriben código en el Bloc de notas.
Una Arquitectura también es un código, y para trabajar con una Arquitectura hay un conjunto de herramientas que es tan poderoso y rico como para trabajar con una Implementación. Google Docs no es la única herramienta de arquitectura que puede usar y está lejos de ser la mejor. Por supuesto, la gama de herramientas listas para usar disponibles para el arquitecto en este momento no es tan amplia como la gama de herramientas para desarrolladores. Y no todo lo que un arquitecto puede usar funciona de inmediato. Aún así, las cosas no están tan mal.
Muchas herramientas han existido durante décadas, como SQL, solo necesita aprender a usarlas correctamente. Las nuevas tecnologías como GraphQL están comenzando a ganar terreno y ofrecen la esperanza de que la tarea de describir un dominio empresarial se convierta con el tiempo en algo tan rutinario como describir un dominio de almacenamiento. Hay disponibles herramientas para la documentación y visualización de la estructura de la aplicación y la API, incluido Swagger. Puede utilizar los mismos marcos y herramientas de integración para probar la Arquitectura como lo haría para probar la Implementación.
Arquitectura - Declarativa. Probablemente, la burocracia del trabajo con documentos nunca desaparecerá por completo del trabajo de un arquitecto, pero ahora su volumen se puede reducir significativamente. La arquitectura también es código y, con el tiempo, las herramientas disponibles para trabajar en la Arquitectura pueden llegar a ser tan avanzadas como las herramientas para trabajar en la Implementación. Veremos.
-
Dmitry Mamonov,
Wrike
PD. Comencé el artículo con una lista de preguntas filosóficas a las que, espero, pude dar respuestas bastante específicas. Al menos ese es mi punto de vista. ¿Encontraste algo útil o nuevo en el artículo? ¿Cómo responde usted mismo a estas preguntas? Escribe en los comentarios.