arquitecturas ágiles

Question

estoy empezando mi tesis de grado y el tema será "arquitecturas ágiles"

Básicamente, se iniciará con una descripción de metodologías más de desarrollo de software tradicionales, y el posterior nacimiento de metodologías ágiles, terminando con las recomendaciones y un diseño de una arquitectura de aplicación flexible fácilmente adaptable a los cambios inherentes en la construcción del software.

Mi pregunta es, ¿qué patrones y prácticas de diseño recomendaría para una arquitectura de este tipo? Me interesan los patrones que permiten la maximización del desacoplamiento de clases como la inyección de dependencia, la alta capacidad de mantenimiento y la máxima abstracción del problema específico.

Answer 1

recomiendo lo siguiente:

1. patrón Repositorio
2. patrón Especificación
3. inyección de dependencias
4. Domain Driven Design

Básicamente todo lo que la multitud ALT.NET predica.

Answer 2

Definitivamente prácticas de IoC y basado en contrato programación en general estaría en la parte superior de mi lista. Sin embargo, por una cuestión de experiencia, me gustaría advertir en contra de abstraer demasiado del problema simplemente por el bien de la abstracción. P.ej. haciendo abstracciones porque puedes y no porque nadie podrá usar esa abstracción. He visto que ese tipo de arquitectura ha ido mal y simplemente agrega un grado demasiado alto de complejidad a un sistema que empeora el mantenimiento del sistema.

Algún tipo de retroalimentación alrededor de su proceso de desarrollo, ya sean pruebas unitarias, integración continua y/o reuniones "scrum". Me doy cuenta de que eso realmente no entra en el ámbito de las "arquitecturas" ágiles, pero si no tiene un proceso ágil, no importará ningún grado de arquitectura "orientada a la agilidad".

Answer 3

Es una pregunta interesante, esto. ¿Se puede crear una arquitectura ágil de forma aislada? Si estamos viendo algo como XP entonces estoy un poco dudoso. O tal vez he entendido mal, pero eso nunca me impidió expandirme ...

En XP, para adoptar un enfoque que conozco más, vamos a tener algún tipo de estructura en muy poco tiempo después de que comenzar un proyecto; sobre el momento en que se completa la primera historia, de hecho. Durante la escritura de la historia inicial, comenzaremos a tener una idea de lo que podríamos construir: es inevitable: los programadores tienden a pensar en términos de código. Pero pensar demasiado adelante nos lleva al territorio YAGNI.

Creo que gran parte de la arquitectura de una aplicación desarrollada dentro de un entorno ágil se espera que sea emergente a través de, en particular, la refactorización constante y dedicada para eliminar la duplicación.

Entonces, quizás la pregunta es tanto para evaluar si hay características particulares - o clases de características - que las arquitecturas desarrolladas como resultado de un proceso ágil tenderán a mostrarse. Y luego creo que dependerá del tipo de aplicación que construyamos, aunque algunos de los principios ya mencionados (algunos de los cuales incluso entiendo) deben ser posibles.

Answer 4

Por lo que a mí respecta, Agile no predica ninguna "Arquitecturas" como tal.Agile es una metodología que se basa en los principios fundamentales que afectan la gestión de proyectos, los ciclos de publicación y la práctica general de desarrollo, pero ciertamente no la arquitectura de software.

Todos los patrones de software enumerados aquí se pueden utilizar mediante un proceso de cascada fuerte que es anatema para el desarrollo ágil.

Answer 5

Onion Architecture

example

Answer 6

Siendo medios ágiles que aceptar el cambio, es decir, adoptar a cambios en las necesidades y decisiones de diseño y aceptar refactorización, etc .. muchas cosas a la manera "tradicional" habría fruncir el ceño a, ya que eres tocando algo que está funcionando/acordado previamente.

En métodos como XP, intenta mantener la calidad alta escribiendo pruebas unitarias. Supongamos que todos estamos de acuerdo en escribir pruebas unitarias.

Ahora aquí es donde puede introducir algo de arquitectura para que el sistema sea comprobable, o prueba fácil, porque no todos los sistemas son verificables. Por ejemplo, hacer que la capa intermedia se pueda llamar y separar la capa de la interfaz de usuario de la lógica empresarial, etc.

Answer 7

Las prácticas de diseño esenciales que sugiero es construir primero un esqueleto funcional de extremo a extremo de su arquitectura. Para validarlo lo antes posible por real feedback.

Esto es lo que los programadores pragmáticos llaman "Tracer Bullets", y Alistair Cockburn como "walking skeleton".

¿Puede definir también qué aplicación es en el contexto de su tesis? ¿Considera solo application software o si también se ocupa de sistemas más complejos?

Answer 8

Si Robert Martin tiene algo que decir al respecto (y llamó al original Agile Manifesto meeting IIRC), entonces absolutamente la arquitectura tiene todo para hacer con Agility. Toda la primera sección de su libro Agile Software Development, Principles, Patterns, and Practices trata sobre los principios arquitectónicos SOLID. Esto ha sido un tanto controvertido en algunos sectores, pero no entiendo por qué. Si su base de código es frágil y fuertemente acoplada, entonces no puede ser muy abierto para cambiar, que es el sello distintivo de la agilidad. El proceso de separación conceptual de la práctica del código es una tarea muy poco ágil.

Principio 1 del manifiesto: "Valoramos las personas y las interacciones sobre los procesos y las herramientas".

La definición de "proceso" ágil como una abstracción separada de la arquitectura de la base de código viola el espíritu de este primer principio.