Diseño dirigido por el dominio DDD

INTRODUCCIÓN

Domain Driven Design (DDD) es un enfoque para el desarrollo de software con necesidades complejas mediante una profunda conexión entre la implementación y los conceptos del modelo y núcleo del negocio. Las premisas del diseño guiado por el dominio son las siguientes:

·         Poner el foco primario del proyecto en el núcleo y la lógica del dominio.

·         Basar los diseños complejos en un modelo.

·         Iniciar una creativa colaboración entre técnicos y expertos del dominio para interactuar lo más cercano posible a los conceptos fundamentales del problema.

DISEÑO DIRIGIDO POR DOMINIOS

El diseño guiado por el dominio provee una estructura de prácticas y terminologías para tomar decisiones de diseño que enfoquen y aceleren el manejo de dominios complejos en los proyectos de software.a

Definiciones Básicas.

·         Dominio: Un campo de conocimiento, influencia o actividad. El área a la que el usuario aplica un programa es el dominio del software.

·         Modelo: un sistema de abstracciones que describe aspectos de un dominio y se puede utilizar para resolver problemas relacionados con ese dominio.

·         Lenguaje Ubicuo: un lenguaje estructurado en torno al modelo de dominio y utilizado por todos los miembros del equipo para conectar todas las actividades del equipo con el software.

·         Contexto: El entorno en el que una palabra o una declaración aparece y el cual determina su significado.

 

Contexto acotado (Bounded Context).

·         Define explícitamente el contexto dentro del cual se aplica un modelo.

·         Establece explícitamente los límites en términos de organización del equipo, el uso de partes específicas de la aplicación, y las manifestaciones físicas, tales como bases de código y los esquemas de bases de datos. Mantiene el modelo estrictamente coherente dentro de estos límites, sin distracción ni confusión por asuntos ajenos.

La integración continúa (Continuous Integration).

·         Establece un proceso de fusión de todo el código y otros artefactos de la aplicación con frecuencia.

·         Se utiliza lenguaje ubicuo para elaborar una visión compartida del modelo y ver como los conceptos evolucionan en la cabeza de diferentes personas.

Mapa de contexto (Context Map).

·         Se identifica cada modelo en juego en el proyecto y se define su contexto acotado.

·         Se incluyen los modelos implícitos de los subsistemas no orientados a objetos.

·         Se identifica el nombre de cada contexto acotado, y se definen parte de estos a través del lenguaje ubicuo.

·         Se describen los puntos de contacto entre los modelos, destacando la clara traducción para cualquier comunicación o intercambio.

Bloques de construcción de DDD.

Una serie de conceptos de alto nivel y prácticas se combinan en el lenguaje ubicuo, el cual debe formar el modelo de dominio. Este lenguaje es definido por los expertos de dominio para describir los requisitos del sistema, y funciona bien tanto para los usuarios de negocios o patrocinadores como para los desarrolladores de software.

Algunos conceptos definidos por DDD son:

·         Entidad: Es un objeto que tiene un identificador único en el contexto que se trata.

·        Value Object: Es un objeto que tiene atributos, pero no tiene identificador en el contexto y sirven para describir cosas.

·         Servicio: aparece cuando tenemos una funcionalidad que no pertenece a ningún objeto del dominio, en tal caso creamos un nuevo objeto que no es del dominio y que tendrá la responsabilidad de realizar esta funcionalidad.

·         Agregado: Es una composición de objetos que tiene una entidad raiz. No hay acceso al contenido del Agregado, y todas las operaciones que se quieran hacer sobre el contenido siempre  se harán a través de la entidad raíz.

·         Factoría: Crea objetos complejos (en muchos casos agregados) y objetos válidos (no devolverá nulos).

·         Repositorio: mantiene constantes las entidades y agregados.

CONCLUSIÓN

      DDD no es ni una tecnología, ni una metodología, es una forma de pensar que ayuda a entender el ámbito para el cual estamos desarrollando software y a formalizar todo el conocimiento que los expertos de dominio tienen en dicho ámbito, en un modelo.

REFERENCIAS:

·         http://en.wikipedia.org/wiki/Domain-driven_design

·         http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=madridAgilDdd

Acta de constitución del proyecto

Software Educacional Mateo

Software MateoNet

¿En qué consiste el programa Mateo?:

El programa mateo es un sistema full web de administración integral para establecimientos educacionales, posee seis módulos principales: Matricula, Académico, Biblioteca, Inventario, Seguridad y acceso especial para los apoderados para entrega de la información académica y conductual a través de Internet.

Se debe iniciar sesión utilizando un navegador web (Mozilla, Internet Explorer), cada establecimiento suscrito a este servicio posee su propia URL (ej. http://www.mateonet.cl/villaalemana) lo lleva al usuario a la siguiente pantalla de login:

De la cual se puede acceder a los diferentes módulos que posee el software.

Funciones de los módulos:

         Módulo de Matriculas:

-Control automático de las becas otorgadas por el colegio

-Generación de distintos planes de pago

-Venta de colegiatura, matrícula y otros ítems.

-Generación y recepción de los documentos de pago de aranceles, matrículas y otros.

-Recepción de la recaudación de pagos mediante caja interna.

-Calculo automático de los montos adeudados.

-Administración de la cartera de documentos por cobrar

-Administración de las cuentas corrientes por apoderado, familia o alumno.

-Generación de los avisos de vencimiento.

-Generación de las credenciales por alumno con fotografía y código de barra.

        Modulo Académico:

-Registro de la ficha de alumnos.

-Mantenimiento de la ficha de la familia y sus integrantes.

-Generación de credenciales para alumnos.

-Generación de los cursos que impartirá el colegio

-Incorporación de herramientas de planificación del año escolar.

-Mantenimiento de la ficha de profesores.

-Control de asistencia de alumnos.

-Control de la asistencia de los profesores.

-Generación de credencial del profesor.

-Administración de la malla académica.

-Emisión de la carta Gantt de trabajo para los docentes.

-Registro de las calificaciones de los alumnos.

-Registro de la conducta, desarrollo personal y anotaciones del alumno.

-Ejecución del proceso de promociones en forma automática.

-Generación de los archivos del RECH.

-Emisión de los diferentes certificados e informes de notas.

-Emisión de la lista de alumnos, informe de pase escolar y otros por curso.

  

  Módulo de Seguridad:

-Asignación de permisos por rol.

-Asignación de permisos por usuario.

-Ingreso y control de Usuario y contraseñas.

-Ingreso de roles.

-Auditoria diaria de procesos críticos con registro de cambios y operaciones realizadas sobre la base de datos de MateoNET.

d       Modulo Biblioteca:

-Ingreso y control de los materiales

-Control de préstamos, prorrogas y devoluciones.

-Solicitud en línea de materiales de biblioteca.

-Informe de morosos.

-Estadística del ranking de materiales.

-Listado de materiales ordenados por distintos criterios.

-Generación de las etiquetas con código de barra.

e           Módulo de Inventario:

-Ingreso y control de los bienes inventariarbles.

-Ingreso de la planta física de dependencia del establecimiento.

-Control de los responsables académicos y administrativos de cada bien.

-Listado de bienes inventariables ordenados por distintos criterios.

f)          Rol de Apoderados:

-Entrega de información académica y financiera a los apoderados a través de internet.

-Posibilidad de que el apoderado pueda enviar observaciones al establecimiento educacional.

El software mateo tiene una apariencia amigable para los usuarios, es fácil de utilizar y ultimamente se ha masificado su uso considerablemente. Tambien la empresa que desarrolla este programa posee otras herramientas adicionales utiles para los establecimientos educacionales como:

MateoTest: Software de ensayo de las pruebas PSU y SIMCE

 

                             SGP: Sistema de gestion de aplicaciones, facilita el diseño                                seguimiento de las planificaciones de un establecimiento educacional.

Aquí se muestra la pantalla principal que muestra cada módulo anteriormente mencionado:

Y algunos otros ejemplos del programa:

Sistema de control de versiones

¿ Qué es el sistema de control de versiones?

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de ellos a lo largo del tiempo, de modo que puedas recuperar versiones especificas mas adelante.

Ejemplos de algunos sistemas de control de versiones:

• CVS
• Subversión
• SourceSafe
• Darcs
• Plastic SCM
• Git
• Mercurial

Todos los sistemas de control de versiones(VCS), nos proporcionan:

• modos de almacenamientos de la  información(código fuente,archivos..)
• posibilidad de cambios sobre esos elementos(añadir,borrar,mover,etc)
• crear informes del estado de los archivos
• registro histórico(de los cambios realizados,versiones anteriores y permite volver a un estado de  versión anterior)
• Se diferencian 2 tipos de VCS los centralizados y los  distribuidos.

Sistema de control de versiones Centralizados:

Existe un repositorio centralizado con todo el  código con un  único administrador,todas las  decisiones importantes necesitan la  aprobación del responsable.

Estos sistemas, como CVS,Subversion y perforce, tienen un único servidor que contiene todos los archivos versionados y varios clientes que descargan los archivos de ese lugar central.Durante muchos años, este ha sido el estándar para el control de versiones.

desventajas:

• Si el servidor se cae durante una hora, entonces durante esa hora nadie puede colaborar o guardar cambios versionados de aquello en que estaba trabajando.
• Si el disco duro en el que se encuentra la base de datos central se corrompe y no se han llevado a cabo copias de seguridad adecuadamente,se pierde absolutamente todo.

Sistema de control de versiones Distribuidos(DVCS):

En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor se cae o "muere", y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes se pueden copiar en el servidor para restaurarlo.

Se pueden crear diferentes grupos de personas, manteniendo la coordinación y trabajar de manera simultanea.

Esto permite establecer varios tipos de flujos de trabajo que NO son posibles en sistemas centralizados, como pueden ser los modelos jerárquicos.

Git como SVC:

Git, es un sistema de control de versiones (SVC) distribuido, creado por Linus Torvalds, que  gestiona los cambios del software, nos facilita la adminitraciòn de los  distintos cambios que se realizan en nuestro proyecto.

Ventajas:

• Velocidad
• Diseño sencillo
• Fuerte apoyo al desarrollo no lineal (miles de ramas paralelas)
• Completamente distribuido
• Capaz de manejar grandes proyectos como el núcleo de Linux de manera eficiente (velocidad y tamaño de los datos)

¿Porque Git y no otro sistema de control de versiones?

Aparte de que Git es un sistema de control de versiones distribuido, otra  principal diferencia entre Git y cualquier otro VCS (Subversion y compañía incluidos) es cómo Git modela sus datos.La mayoría de los demás sistemas almacenan la información como una lista de cambios en los archivos, como en la siguiente figura:

Otros sistemas tienden a almacenar los datos como cambios de cada archivo respecto a una versión base.

Git modela sus datos más como un conjunto de instantáneas de un mini sistema de archivos. Cada vez que confirmas un cambio, o guardas el estado de tu proyecto en Git, él básicamente hace una foto del aspecto de todos tus archivos en ese momento, y guarda una referencia a esa instantánea. Para ser eficiente, si los archivos no se han modificado, Git no almacena el archivo de nuevo — sólo un enlace al archivo anterior idéntico que ya tiene almacenado, como en la siguiente figura:

Los 3 estados de Git

Git tiene tres estados principales en los que se pueden encontrar tus archivos: confirmado (committed), modificado (modified), y preparado (staged). Confirmado significa que los datos están almacenados de manera segura en tu base de datos local. Modificado significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos. Preparado significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación(commit).

Esto nos lleva a las tres secciones principales de un proyecto de Git: el directorio de Git (Git directory), el directorio de trabajo (working directory), y el área de preparación (staging area).

Directorio de trabajo, área de preparación, y directorio de Git

                            

El directorio de Git es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador.

El directorio de trabajo es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar o modificar.

El área de preparación es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación. A veces se denomina el índice, pero se está convirtiendo en estándar el referirse a ello como el área de preparación.

El flujo de trabajo básico en Git es algo así:

1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de preparación.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación, y almacena esa instantánea de manera permanente en tu directorio de Git.

Si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified). 

Estado de los archivos en Git

Cada archivo que se encuentra en el direciorio de trabajo puede estar en uno de 2 estados:

• Tracked(rastreado por Git) :

            Son aquellos archivos que fueron commiteados o son aquellos que fueron clonados de un proyecto que ya estaba en marcha.Los archivos tracked que no han sido modificados son unmodifieded(no han sido modificados), si se editan o cambia  algún archivo, pasan a ser modified(modificados),si se usa el comando git add para añadir esos archivos modified, entonces se dice que estan en el staged, listos para se commiteados.

•  untracked(no rastreado por Git):

          Son aquellos archivos que fueron recién creados en nuestro directorio local y por lo tanto no esta siendo seguido por Git, y es un archivo que no se ha commiteado, una vez que sea haga un commit sobre el o se suba al repositorio local, entonces estara Tracked.

En la siguiente figura se muestra este ciclo.

Fuente: http://git-scm.com/ (pagina oficial de git)