Patrones de diseño en capas múltiples

 Se basa en la separación de los procesos en unidades llamadas capas y es la arquitectura por defecto usados en aplicaciones JAVA.

Cada capa cumple una función especifica, como por ejemplo , podemos tener una capa para la parte visual de la aplicación y sólo tenemos en esta capa lo relacionado con ello.

Existen muchas implementaciones de esta arquitectura con diferentes cantidades de capas , según las necesidades del proyecto.

Patrones de diseño microkernels

 También conocido como arquitectura de plugin es muy popular para aplicaciones que necesitar utilizar software de terceros o agregar funcionalidades adicionales.

En esta arquitectura, los componentes se dividen en dos tipo:

• Núcleo central, donde se encuentran todas las funciones criticas de la aplicación, es independiente y funcional, no requiere de ningún otro elemento para trabajar, sin embargo su funcionalidad se restringe a los procesos básicos, como gestión de hardware, interfaz gráfica o paquetes de uso común.
• Plug-ins son módulos autocontenidos con una funcionalidad especializada y dependen del entorno que provee el núcleo central para extender o modificar su funcionalidad.

Entre las ventajas que ofrece esta arquitectura está su enorme flexibilidad, y la facilidad en realizar pruebas, lo que reduce el índice de errores.

Y por otro lado, una desventaja de está arquitectura es que al estar todo centralizado en un núcleo central, no son fáciles de escalar para  uso masivo.

Patrones de diseño microservicios

 Sí una aplicación monolítica concentra toda su funcionalidad en un solo punto, los microservicios son todos los puestos, distribuyendo os procesos en múltiples `partes más pequeñas e independientes.

Existen distintas maneras de implementar el patrón de diseño de microservicios,  podemos encontrar algunos elementos comunes entre ellos, como la distribución de tareas en bloques separados.

Estos bloques se llaman componentes de servicios y agrupan uno o varios componentes enfocados en realizar una tarea o un área de negocio de la aplicación. Esto componentes de servicios están completamente desacoplados entre sí y funcionan de forma completamente independiente lo que permite que cualquiera de ellos puedan ser reemplazados. sin afectar al resto de la aplicación.

Se aconseja en este tipo de patrón de diseño que las bbdd también estén desacopladas y se realice a través de la APIs Rest. Esto permite a los arquitectos tener puntos de entradas y salidas de datos que pueden estar a su vez encapsulados en sus propios componentes de servicios creando APIs consistentes y a la vez flexibles que pueden interactuar con diferentes bases de datos.

Patrones de diseño frente a Principios de diseño

• Los principios de diseño son pautas generales que pueden guiar la estructura y las relaciones de clase. Todo desarrollo, antes o después, se ve sometido a cambios sobre la funcionalidad inicial o simplemente se requiere funcionalidad nueva. Estos principios nos proporcionan unas bases para la construcción de aplicaciones mucho más sólidas y robustas. Permiten que los cambios y la evolución del software tenga un mínimo impacto en el código ya desarrollado tratando de evitar que lo que funciona deje de funcionar y por ello que el coste del mantenimiento sea mucho menor.

• Los patrones de diseño son soluciones probadas que resuelven problemas recurrentes. Dicho esto, la mayoría de las implementaciones prácticas de estos principios de diseño se realizan principalmente utilizando uno o más patrones de diseño.

Principios de diseño de software

 Algunos de estos Principios de Diseño son:

• Encapsular lo que varía --> Considerado como los principios fundacionales del diseño, este principio se encuentra en funcionamiento en casi todos los patrones de diseño.                             Este principio sugiere, identificar los aspectos de sus aplicaciones que varían y separarlos de lo que permanece igual. Si un componente o módulo de tu aplicación está destinado a cambiar con frecuencia, entonces es una buena práctica separar esta parte del código de los estables para que después podamos ampliar o alterar la parte que varía sin afectar a los que no varían. La mayoría de los patrones de diseño como Strategy, Adapter, Facade, Decorator, Observer, etc siguen este principio. 
• Favorecer la composición sobre la herencia-->La programación orientada a objetos proporciona 2 tipos de relaciones entre las clases y sus instancias: has-a (composición) e is-a (herencia). Este principio de diseño nos sugiere esencialmente que "la relación has-a debe ser preferida sobre la relación is-a.". A veces la herencia cuando se usa en exceso hace que nuestro código sea más rígido y no extensible.
• Programa a interfaces-->Este principio de diseño nos guía para hacer uso de los tipos abstractos y no de los concretos. "Programar para interfaces" significa en realidad programar para un supertipo como una interfaz o una clase abstracta en java.
• Acoplamiento flexible-->Es un principio que sugiere que "los componentes que interactúan entre sí deben ser independientes unos de otros, confiando lo menos posible en el conocimiento de otro componente". Este es un principio que seguimos en una arquitectura de microservicios. Los servicios que interactúan entre sí son independientes unos de otros. La interacción se basa estrictamente en los contratos de datos. La implementación del acoplamiento flexible variará de un escenario a otro en función del problema que tratemos de resolver.
• Principios SÓLIDOS-->Es un conjunto de 5 principios que forman el acrónimo:
• Principio de responsabilidad única (Single responsibility principle): Una clase debe tener una sola razón para cambiar. Este principio sugiere que las responsabilidades de una clase deben ser limitadas. No es una directriz clara porque no tenemos una instrucción específica en la que basarnos para juzgar esto. Sin embargo, la idea básica cuando se diseña usando este principio debería ser comprobar si los métodos dentro de una clase están cohesionados, es decir, ¿realmente necesitan estar juntos?
• Principio de apertura y cierre (Open closed principle): Este principio establece que nuestro diseño debe estar abierto a la ampliación pero cerrado a las modificaciones. ¿Pero qué pasa si queremos añadir una nueva implementación en nuestro diseño? Podemos abordar esto de dos maneras:
• Extendemos la funcionalidad existente a una nueva clase y añadimos las implementaciones allí
• Utilizar la composición para aceptar nuevos comportamientos
• Principio de sustitución de Liskov (Liskov’s substitution principle):A veces la herencia puede romper el sistema cuando sustituimos nuestra clase derivada por la clase padre. El principio de Liskov sugiere esencialmente que: "Siempre deberías poder sustituir los subtipos por su clase base".
• Principio de segregación de la interfaz (Interface segregation principle): Este principio sugiere que una "interfaz debe estar siempre cohesionada". Es decir, los componentes de la interfaz deben estar muy relacionados entre sí. Cualquier componente que no esté relacionado entre sí debe ser separado y segregado.
• Principio de inversión de la dependencia (Dependency inversion principle): El principio de inversión de la dependencia se utiliza para desacoplar los módulos de software. Establece que "los módulos de alto nivel no deben depender de los de bajo nivel. En cambio, ambos deben depender de la abstracción".

Los principios de diseño que se han tratado en este artículo son los más fundamentales. Hay algunos principios más como

• DRY significa "Don't Repeat Yourself" (no te repitas), que establece que "cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada dentro de un sistema". En otras palabras, significa que cada módulo debe ser único en sí mismo.
• AHA significa Avoid Hasty Abstractions, que básicamente nos sugiere que a veces las abstracciones pueden llevar a una base de código rígida. Y cuando lo hacen, es mejor evitarlas.
• KISS son las siglas de Keep It Simple Stupid (Manténgalo Simple y Estúpido), que sugiere que nuestra implementación debe ser lo más simple posible. Cualquier cosa que introduzca complicaciones en la implementación debe ser desacoplada utilizando cualquiera de los principios anteriores.