Pregunta

Estoy iniciando mi tesis de posgrado y el tema será "arquitecturas ágiles"

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

Mi pregunta es, ¿qué patrones y prácticas de diseño recomendaría para dicha arquitectura?Estoy interesado en patrones que permitan maximizar el desacoplamiento de clases, como la inyección de dependencia, alta capacidad de mantenimiento y máxima abstracción del problema específico.

¿Fue útil?

Solución

Recomiendo lo siguiente:

  1. Patrón de repositorio
  2. Patrón de especificación
  3. Inyección de dependencia
  4. Diseño impulsado por dominio

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

Otros consejos

Definitivamente las prácticas de IoC y basado en contrato La programación en general estaría en la parte superior de mi lista.Sin embargo, por una cuestión de experiencia, advertiría que no se debe abstraer demasiado del problema simplemente por el simple hecho de abstraerse.P.ej.abstraer porque se puede y no porque alguien pueda alguna vez hacer uso de esa abstracción.He visto ese tipo de arquitectura que sale mal y simplemente agrega un grado demasiado alto de complejidad a un sistema, lo que empeora el mantenimiento del sistema.

Algún tipo de circuito 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 alcance de las "arquitecturas" ágiles, pero si no tiene un proceso ágil, ningún grado de arquitectura "orientada a ágil" importará.

Una práctica de diseño esencial que sugeriría es construir primero un esqueleto funcional de extremo a extremo de su arquitectura.Validarlo lo antes posible mediante comentarios reales.

Esto es lo que los programadores pragmáticos denominan "balas rastreadoras" y Alistair Cockburn como "balas rastreadoras".esqueleto andante".

¿Puede definir también qué es una aplicación en el contexto de su tesis?¿Solo consideras Software de la aplicacion ¿O también trata con sistemas más complejos?

Es una pregunta interesante.¿Se puede crear una arquitectura ágil de forma aislada?Si estamos viendo algo como XP entonces tengo algunas dudas.O tal vez lo he entendido mal, pero eso nunca me ha impedido expandirme...

En XP, para adoptar un enfoque del que conozco más, vamos a tener algún tipo de estructura en muy poco tiempo después de iniciar un proyecto;De hecho, aproximadamente cuando se completa la primera historia.Durante la redacción inicial de la historia habremos empezado 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 en el futuro nos lleva a YAGNI territorio.

En cierto modo pensé que se esperaría que gran parte de la arquitectura de una aplicación desarrollada dentro de un entorno ágil surgiera, en particular, a través de una refactorización constante y dedicada para eliminar la duplicación.

Entonces, tal vez la cuestión sea evaluar si hay características particulares (o clases de características) que las arquitecturas evolucionadas como resultado de un proceso ágil tenderán a mostrar.Y luego creo que dependerá del tipo de aplicación que estemos creando, aunque algunos de los principios ya mencionados (algunos de los cuales incluso entiendo) deben ser probables.

En lo que a mí respecta, Agile no predica ninguna "Arquitectura" como tal.Agile es una metodología que se basa en principios fundamentales que afectan la gestión de proyectos, los ciclos de lanzamiento y las prácticas generales de desarrollo, pero ciertamente no la arquitectura de software.

Todos los patrones de software enumerados aquí podrían usarse mediante un sólido proceso en cascada que es un anatema para el desarrollo ágil.

Ser ágil significa aceptar el cambio, es deciradoptar cambios en los requisitos y decisiones de diseño y aceptar refactorizaciones, etc.Muchas cosas de la manera "tradicional" estarían mal vistas, ya que estás tocando algo que funciona o que está previamente acordado.

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

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

Si Robert Martin tiene algo que decir al respecto (y llamó a la reunión IIRC del Manifiesto Ágil original), entonces absolutamente la arquitectura tiene todo que ver con la Agilidad.Toda la primera sección de su libro. Desarrollo, principios, patrones y prácticas de software ágil se trata del SÓLIDO principios arquitectónicos.Esto ha sido algo controvertido en algunos sectores, pero no entiendo por qué.Si su código base es frágil y está muy acoplado, entonces no puede estar muy abierto al cambio, que es el sello distintivo de la agilidad.Separar conceptualmente el proceso de la práctica del código es algo muy poco ágil.

Principio 1 del manifiesto:"Valoramos a las personas y las interacciones por encima de los procesos y las herramientas".

Para mí, definir el "proceso" ágil como una abstracción separada de la arquitectura del código base viola el espíritu de este primer principio.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top