¿Es la "arquitectura de software evolutiva" una contradicción?


8

En mi opinión, la arquitectura evolutiva se reduce a hacer que la arquitectura sea fácil de modificar. Ahora, la arquitectura a menudo se define como las cosas que debes hacer bien temprano porque serán difíciles de cambiar más adelante.

¿Cómo encaja esto? ¿Hay alguna diferencia entre la arquitectura evolutiva y simplemente minimizar la cantidad de arquitectura?


"La arquitectura a menudo se define como las cosas que debe acertar temprano porque serán difíciles de cambiar más adelante". A MENOS QUE espere que cambien. Eso hace una gran diferencia y da espacio para la evolución futura.
Tomasz Maciejewski

Estoy de acuerdo en que es una contradicción en términos, si define la arquitectura como "todo lo que es costoso cambiar más tarde", que es la mejor definición que he escuchado hasta la fecha. Sin embargo, no estoy de acuerdo con "deberías hacerlo bien temprano", esta definición es la razón por la que uno debe posponer las decisiones arquitectónicas el mayor tiempo posible (para que puedan estar lo más informadas posible).
Martin Maat

Respuestas:


20

La nota clave de Neal Ford sobre Arquitectura Evolutiva se puede encontrar aquí.

Parafraseando:

La arquitectura son las decisiones que desearía poder tomar al principio de un proyecto, cosas que las personas perciben como difíciles de cambiar. Pero, ¿y si construimos arquitecturas que esperan un cambio?

Una arquitectura evolutiva admite el cambio gradual guiado como primer principio en múltiples dimensiones.

Continúa describiendo diferentes escenarios arquitectónicos, comenzando con Big Ball of Mud, arquitecturas en capas, microkernels y REST, y culminando en microservicios, que según él tienen n dimensiones de capacidad evolutiva (donde n es el número de microservicios distintos).

Según Ford, las arquitecturas evolutivas:

  • Están sueltos y altamente cohesivos ,
  • Son compostables; los componentes se pueden ensamblar para crear nuevas arquitecturas,
  • Se puede cambiar de forma incremental, sin necesidad de una revisión arquitectónica.

Puede pensar en la Arquitectura Evolutiva como una metaarquitectura, si lo desea; Una arquitectura de arquitecturas. Orientación que dicta los principios de diseño que promueven la fundición de objetos en arcilla en lugar de piedra.


2
Estoy de acuerdo en que poner la palabra "evolutivo" delante de la palabra "arquitectura" significa que no es "arquitectura" en el sentido "tradicional".
Robert Harvey

77
Puedo pensar más fácilmente que le da un nuevo nombre a las mismas cosas de siempre. Cada metodología de software que puedo recordar ha afirmado que la adaptabilidad al cambio es una de sus cualidades. Si esto es único, se trata principalmente de proporcionar incluso menos detalles que otros sobre cómo lograrlo.
Jerry Coffin

2
@Euphoric: Eso no encaja con lo que (por ejemplo) Hoare y Dijkstra dijeron cuando la programación estructurada era nueva, ni lo que Booch, Meyer, etc., dijeron cuando OOP era nueva, etc. Más bien lo contrario: la mayoría abogó por que la mayoría de lo que haría sería crear pequeñas piezas que fueran reutilizables, por lo que la mayoría de los cambios se restringieron a la arquitectura. Tendría pequeñas piezas agradables que podría reutilizar fácilmente de diferentes maneras, porque la arquitectura iba a cambiar.
Jerry Coffin

1
@Euphoric: Yo diría que más bien lo contrario: estructurada y la programación orientada a objetos (para dos ejemplos) sobre todo hizo cumplir sus promesas. Es más difícil decir mucho sobre este tema: no espero muchos detalles en una nota clave, pero al menos, parece más bombo y menos sustancia que la mayoría de los predecesores.
Jerry Coffin

1
@Eufórico: en gran medida, sí, lo hicieron. Gran parte de lo que es rutinario hoy en día sería mucho más probable que falle usando métodos más antiguos. He estado involucrado en la construcción de un par de sistemas que apenas puedo imaginar intentar con métodos más antiguos (aunque sí, supongo que hubiera sido posible). En cuanto a leer el libro, sí, probablemente lo haré, pero aún no lo he hecho.
Jerry Coffin

1

Sí, es una contradicción si está haciendo que todo sea fácil de cambiar indiscriminadamente. Si tiene que agregar código para hacer algo "más fácil de cambiar" (con "más fácil" mal definido, como aquí), entonces ha dificultado el cambio, simplemente porque agregó código. Por otro lado, si sabe exactamente qué va a cambiar, lo cual es muy poco probable, el código adicional no debe verse como una complejidad innecesaria.

Hacer que las cosas sean "fáciles de cambiar" es probablemente la razón principal por la que gran parte del software moderno se ha vuelto tan hinchado y difícil de cambiar.


Muy cierto, pero realmente no responde a mi pregunta.
Frank Puffer

Hmm, la respuesta a tu pregunta es "Sí".
Frank Hileman el
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.