Patrones: Modelo Vista Controlador Modelo-vista-controlador (MVC) es un patrón de arquitectura de software, que separa los datos y la lógica de negocio de una aplicación de su representación y el módulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construcción de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representación de la información, y por otro lado para la interacción del usuario. Este patrón de arquitectura de software se basa en las ideas de reutilización de código y la separación de conceptos, características que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento. Patrones: Capas Al pensar en un sistema en términos de capas, se imaginan los principales subsistemas de software ubicados de la misma forma que las capas de un pastel, donde cada capa descansa sobre la inferior. A continuación se describen las tres capas principales de un patrón de arquitectura por capas: 1. Capa de Aplicación: Referente a la interacción entre el usuario y el software. Puede ser tan simple como un menú basado en líneas de comando o tan complejo como una aplicación basada en formas. 2. Capa de Lógica de Dominio: Esta capa contiene la funcionalidad que implementa la aplicación. Involucra cálculos basados en la información dada por el usuario y datos almacenados y validaciones. Controla la ejecución de la capa de acceso a datos y servicios externos. 3. Capa de Datos: Esta capa contiene la lógica de comunicación con otros sistemas que llevan a cabo tareas por la aplicación. Generalmente está representada por una base de datos, que es responsable por el almacenamiento persistente de información. El patrón por capas, es el mas usado como base. Junto con este se implementan adicional otro patrones. Una buena propuesta de Arquitectura con N Capas es el propuesto por microsoft en el siguiente libro: Guía de Arquitectura de N-Capas orientada al Dominio con .NET 4.0 Patrones: Orientado a eventos / Provisión de eventos. Arquitectura dirigida por eventos (Event-driven architecture o EDA): Es un patrón de arquitectura software que para orquestar su comportamiento se centra en torno a la producción, detección, consumo y respuestas ante “eventos”. Teniendo en cuenta que un evento es: cualquier ocurrencia identificable que tiene un significado para el hardware o el software del sistema, en otras palabras, cualquier cambio de estado significante para el sistema. Y a su vez este cambio de estado puede ser conocido por otras aplicaciones en la arquitectura, o sea, que cada evento se propaga de manera inmediata a otras partes del sistema en la medida que sea necesario. Patrones: Microkernel - Plug-ins Microkernel - Plug-ins Esta arquitectura esta compuesta por 2 componentes, el sistema core y los modulos plug-in. El core contiene la minima funcionalidad y los módulos plug-in son componentes autónomos e independientes que contienen procesamiento especializado, características adicionales y código personalizado que está diseñado para mejorar o ampliar el sistema central para producir capacidades empresariales adicionales. Generalmente, los módulos plug-in deben ser independientes de otros módulos plug-in, pero ciertamente puede diseñar plug-ins que requieran que otros plug-ins estén presentes. De cualquier manera, es importante mantener la comunicación entre plug-ins a un mínimo para evitar problemas de dependencia. Cuando leemos esto lo primero que se nos viene a la mente es OSGi, porque este estándar nació para darle soporte a este tipo de arquitecturas y el ejemplo más significativo de esta arquitectura sea eclipse. Dejo link:https://www.oreilly.com/ideas/software-architecture-patterns/page/4/microkernelarchitecture 3 Patrones: Comparte-nada Patrones: Comparte-Nada Compartir recursos entre diferentes componentes agrega mucha complejidad a la hora de decidir prioridades o disponibilidad del componente, entonces se busca crear que NO se tenga punto de unión entre componentes. Esta arquitectura es muy potente al procesar la información ya que al separar los componentes se puede enfocar en el fallo por que cada componente hace uso único de los recursos de dicho sistema. Patrones: CQRS CQRS: La segregación de responsabilidades de consultas y comandos (CQRS), Es un estilo de arquitectura que separa las operaciones de lectura de las operaciones de escritura. Los comandos, Deberían basarse en tareas, en lugar de centrarse en datos. (“Reservar habitación de hotel” y no “Establecer ReservationStatus en Reservado”). Los comandos se pueden colocar en una cola para un procesamiento asincrónico, en lugar de que se procesen de forma sincrónica. Las consultas, Nunca modifican la base de datos. Una consulta devuelve un DTO que no encapsula ningún conocimiento del dominio. Patrones: Hexagonal - Puertos y adaptadores La arquitectura hexagonal, Es un estilo de arquitectura que mueve el foco de un programador desde un plano más conceptual hacia la distinción entre el interior y el exterior del software. La parte interior son los casos prácticos y el modelo domain está construido sobre ello. La parte exterior es UI, base de datos, mensajería, etc. La conexión entre el interior y el exterior es mediante puertos, y su implementación equivalente se conocen como adaptadores. Por esta razón, este estilo de arquitectura se conoce habitualmente como Puertos y Adaptadores. Patrones: Diseño orientado al dominio Diseño orientado al dominio Lo que hacemos es guiar nuestra aplicación y el diseño a través del uso del lenguaje común entre el negocio y el desarrollo. El obtener ese lenguaje del negocio y el poder hacer aplicaciones que estén concentradas en eso mucho más que lo que están concentradas en detalles técnicos. Va más allá de una sola aplicación, nos dice que busquemos modularizar nuestro sistema a través de los bounded context, que tratan de encontrar dónde el lenguaje cambia de sentido. ● ● ● ● ● ● El diseño orientado al dominio genera módulos que se puedan desplegar por separado Guiar la aplicación através del uso del lenguaje común entre el negocio y el desarrollo Concentrar en ello las aplicaciones y no en el detalle técnico. Dice que se debe intentar modularizar la aplicación en Bounded Context. Tratan de encontrar donde el lenguaje cambia de sentido -> bounded context En el contexto de ventas el significado de producto es otro en comparación con el significado de inventarios. Aprovecha la separación semántica (propuesta por el negocio) para así separar nuestra aplicación
