LAYER

Layers **

Cuando transformas un modelo de dominio (182) en una técnica de arquitectura de software o se realiza un BROKER (237), DATABASE ACCESS LAYER (438), MICROKERNEL (194), o HALF-SYNC/HALF-ASYNC (359) . . .

.. . hay que apoyar el desarrollo independiente y la evolución de diferentes partes del sistema.

✦✦✦

Independientemente de las interacciones y de acoplamiento entre las diferentes partes de un sistema de software, hay una necesidad de desarrollar y evolucionar de manera independiente, por ejemplo debido al tamaño del sistema y los requisitos de tiempo de salida al mercado. Sin embargo, sin una separación clara y razonada de las preocupaciones de la arquitectura software del sistema, las interacciones entre las partes no pueden contar con el apoyo adecuado, ni tampoco su desarrollo independiente.

El desafío es encontrar un equilibrio entre un diseño que divide la aplicación en partes significativas y tangibles que se pueden desarrollar y desplegar de forma independiente, pero que no se pierda en una gran variedad de detalles para que la visión de la arquitectura y las cuestiones operativas, tales como el rendimiento y la escalabilidad se traten adecuadamente. Un grupo especial, el diseño monolítico no es una opción viable para resolver el problema. Si bien permite la calidad de los aspectos de servicio a abordar más directamente, es probable que resulte en una estructura espagueti que degrada las cualidades de desarrollo tales como comprensibilidad y facilidad de mantenimiento.

Definir una o más capas para el software en desarrollo, con cada capa que tiene una responsabilidad diferente y específico.

Asignar la funcionalidad del sistema a las respectivas capas, y dejar que la funcionalidad de una capa particular sólo se base en la funcionalidad ofrecida por las mismas capas o inferior. Proporcionar todas las capas con una interfaz que esté separada de su aplicación, y dentro de cada programa de capa usar estas interfaces sólo cuando se accede a otras capas.

✦✦✦

Una arquitectura en CAPAS define una partición horizontal de la funcionalidad de un software de acuerdo con subsistemas, de manera que cada grupo de funcionalidades está claramente encapsulado y puede evolucionar independientemente. Los criterios específicos de partición se puede definir a lo largo de varias dimensiones, tales como la abstracción, granularidad, distancia hardware, y la tasa de cambio.

Por ejemplo, una disposición en capas, con las siguientes particiones de una arquitectura: presentación, lógica de aplicación, y los datos persistentes que sigue la dimensión abstracción. Una capa que introduce los objetos de negocio cuyas entidades son utilizados por una capa de procesos de negocios sigue dimensión de granularidad, mientras que uno que sugiere un sistema operativo, una capa de protocolo de comunicación, y una capa con la funcionalidad de la aplicación sigue la dimensión distancia hardware.

Un desafío clave es encontrar el "correcto" número de capas. Muy pocas capas pueden no separar suficientemente los diferentes temas en el sistema que puede evolucionar de forma independiente. Por el contrario, demasiadas capas pueden fragmentar una arquitectura de software en pedazos sin una clara visión y alcance, lo que hace que sea difícil para ellos evolucionan en absoluto.

Normalmente, cada responsabilidad autónoma y coherente dentro de una capa se realiza como un objeto de dominio por separado, para dividir aún más la capa en partes tangibles que pueden ser desarrolladas y evolucionaron de forma independiente.

NOTA

 

Tipo: Arquitectónico

Estructura una aplicación en diferentes en grupos - de diferentes niveles - subtareas.