Las metodologías de desarrollo de software clásicas se caracterizan por definir total y rígidamente los requisitos al inicio de los proyectos de ingeniería de software. Los ciclos de desarrollo son poco flexibles y no permiten realizar cambio. (Santander Universidades, s.f.)

La organización del trabajo de las metodologías tradicionales es lineal, es decir, las etapas se suceden una tras otra y no se puede empezar la siguiente sin terminar la anterior. Tampoco se puede volver hacia atrás una vez se ha cambiado de etapa. (Santander Universidades, s.f.)

Metodologías

Método de cascada

Es el enfoque metodológico que ordena rigurosamente las etapas del ciclo de vida del software, de forma tal que el inicio de cada etapa debe esperar a la finalización de la inmediatamente anterior. (UNAM)

Método de prototipos evolutivos

Se basa en la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. (UNAM)

Las fases que lo comprenden son: 1) de investigación preliminar, 2) definición de los requerimientos del sistema, 3) de diseño técnico, 4) de desarrollo y pruebas, 5) de operación y mantenimiento. (UNAM)

Método incremental

En esta metodología de desarrollo de software se va construyendo el producto final de manera progresiva. En cada etapa incremental se agrega una nueva funcionalidad, lo que permite ver resultados de una forma más rápida en comparación con el modelo en cascada. El software se puede empezar a utilizar incluso antes de que se complete totalmente y, en general, es mucho más flexible que las demás metodologías. (Santander Universidades, s.f.)

Método en espiral

Es una combinación de los dos modelos anteriores, que añade el concepto de análisis de riesgo. Se divide en cuatro etapas: planificación, análisis de riesgo, desarrollo de prototipo y evaluación del cliente. El nombre de esta metodología da nombre a su funcionamiento, ya que se van procesando las etapas en forma de espiral. Cuanto más cerca del centro se está, más avanzado está el proyecto. (Santander Universidades, s.f.)

Metodología de diseño rápido de aplicaciones

Esta metodología permite desarrollar software de alta calidad en un corto periodo de tiempo. Los costes son mucho más altos y el desarrollo más flexible, aunque requiere una mayor intervención de los usuarios. Por otro lado, el código puede contener más errores, y sus funciones son limitadas debido al poco tiempo del que se dispone para desarrollarlas. El objetivo es iterar el menor número posible de veces para conseguir una aplicación completa de forma rápida. (Santander Universidades, s.f.)

Patrones de diseño

Un patrón de diseño es una solución repetible y general para problemas de ocurrencia cotidianos en el diseño de software. Un patrón de diseño no es un diseño de software terminado y listo para codificarse, más bien es una descripción o modelo (template) de cómo resolver un problema que puede utilizarse en diferentes situaciones. (Nakayama C & Solano Gálvez)

¿Qué es el diseño de capas de dominio?

El estilo en capas considera la arquitectura como un sistema en capas ordenadas. Un programa ubicado en un nivel o capa puede obtener los servicios de un nivel inferior.  (Estevez)

Es un estilo simple y de uso clásico para desarrollos en lenguajes de programación como Java o C. (Estevez)

¿Qué son los patrones de dominio?

Son soluciones a problemas recurrentes y específicos en un negocio determinado. Están enfocados a resolver problemas en una industria específica. Son modelos conceptuales generalistas sobre los tipos de negocios más habituales. Tareas que la aplicación necesita realizar para cumplir con los requerimientos del negocio que resuelve la aplicación. (Estevez)

¿En qué consiste los patrones de diseño de la capa de dominio?

Son soluciones recurrentes a problemas específicos con la lógica del negocio y las reglas del dominio de una aplicación. (Estevez)

Transaction Script

Este patrón de capa de dominio organiza la lógica de negocio por procedimiento, donde cada procedimiento maneja un único pedido desde la capa de presentación. (Estevez)

Un Transaction Script organiza cada transacción de negocio (funcionalidad) en un único procedimiento, haciendo las llamadas pertinentes a la capa de acceso a datos. Cada transacción de negocio tendrá su propio Transaction Script, aunque sub-tareas comunes pueden ser aisladas en sub-procedimientos. (Estevez)

Un Transaction Script se podría resumir en validar los datos de entrada, consultar la base de datos, realizar cálculos y guardar los resultados en la base de datos. (Estevez)

Usos del Transaction Script

Ventajas:

Dada su simplicidad, es natural utilizarlo en aplicaciones que tengan poca lógica de negocios, ya que involucra poco overhead tanto en performance como en curva de aprendizaje. (Estevez)

Limitaciones:

A medida que la lógica de negocio se torna más compleja, es difícil mantenerlo con un buen diseño. (Estevez)

Generalmente se tiene problemas con la duplicación de código. Puesto que el foco está en resolver una transacción, muchas veces se tiende a duplicar código común. (Estevez)

Domain Model

Este patrón de capa de dominio es un modelo de objetos del dominio que incorpora tanto comportamiento como datos. (Estevez)

Un Domain Model crea una red de objetos interconectados, donde cada objeto representa a un concepto significativo, ya sea tan grande como una corporación o tan pequeño como un ítem de una factura. (Estevez)

Tipos de Domain Model:

• Simple. Luce muy parecido al modelo de base de datos, normalmente con un objeto de dominio por cada tabla de la base de datos. Puede utilizar el patrón Active Record 1para el acceso a datos. (Estevez)
• Rico. Puede lucir diferente al modelo de base de datos, incorporando herencia, strategies, otros patrones de diseño orientados a objetos [GoF] y redes complejas de pequeños objetos interconectados. Requiere utilizar el patrón Data Mapper2 para el acceso a datos. (Estevez)

Uso de Domain Model

Complejidad de comportamiento del sistema:

Si tenemos reglas de negocio complicadas y cambiantes que involucran validaciones, cálculos, etc., sería preferida la utilización de un Domain Model. En cambio, si solamente se tienen chequeos de campos requeridos y un par de sumas para realizar, probablemente sea suficiente con Transaction Script. (Estevez)

Comodidad del equipo en el uso de objetos de domino:

Aprender a diseñar y usar un Domain Model es un ejercicio significativo. Principalmente lleva práctica y coaching, pero una vez que se utiliza correctamente pocos profesionales quieren volver a un Transaction Script para situaciones algo o muy complejas.

Posibilidad de utilizar un Data Mapper para el acceso a datos:

En algunas circunstancias, no es posible o lleva mucho esfuerzo utilizar un Data Mapper y esto complica la utilización de Domain Model.