Particionamiento de la arquitectura

Una de las principales decisiones que un arquitecto debe tomar se refiere a la división de alto nivel de la arquitectura. Para esto, los arquitectos suelen pensar en términos de componentes, la manifestación física de un módulo. Los componentes representan la unidades de construcción básica en la arquitectura, lo que los convierte en una consideración crítica para los arquitectos.

Los componentes se pueden manifestar de diferentes formas:

• Library
• Layer
• Event Processor
• Distributed service

Por lo general, el componente es el nivel más bajo del sistema de software con el que un arquitecto interactúa directamente. Los componentes consisten en clases o funciones (dependiendo del paradigma de programación), cuyo diseño es responsabilidad de los desarrolladores. 

Tipos de particionamiento

Cuando un arquitecto realiza la división de alto nivel de la arquitectura, genera componentes utilizando un tipo de particionamiento en particular, que puede ser:

• Particionamiento técnico
• Particionamiento por dominio

Tipos de particionamiento de alto nivel

El particionamiento de alto nivel es de particular interés para los arquitectos porque define el estilo de arquitectura a usar, ya sea monolítico o distribuido:

• Monolithic: Layered architecture, Pipeline architecture, Microkernel architecture
• Distributed: Service-based architecture, Event-driven architecture, Space-based architecture, Service-oriented architecture, Microservices architecture

Por eso pregúntate ¿qué tipo de particionamiento soporta el estilo arquitectónico que estoy analizando?

Particionamiento técnico

Consiste en dividir la arquitectura en capacidades técnicas. Un ejemplo de esto es la arquitectura en capas, la cual representa una división técnica de alto nivel: presentación, reglas de negocio, servicios, persistencia, etc.

Particionamiento por dominio

Este tipo de particionamiento está inspirado en el libro de Eric Evans Domain-Driven Design (DDD) en donde explica una técnica de modelado para descomponer sistemas complejos. En DDD el arquitecto identifica los dominios o flujos de trabajo independientes y desacoplados entre sí. El estilo arquitectónico de microservicios se basa en este enfoque.

Flujo de identificación de componentes

La propuesta para la identificación de componentes es seguir una serie de pasos bajo un enfoque iterativo. Ya sea para la identificación de componentes candidatos o el refinamiento de los mismos.

• Identifying Initial Components: Basándose en un tipo de particionamiento de alto nivel, determinar con qué componentes comenzar. Es difícil empezar con algo concreto cuando un arquitecto diseña un sistema desde cero. Para lograr un buen diseño no queda otra opción que iterar.
• Assign Requirements to Components: Mapear los requisitos funcionales con los componentes. Esto puede implicar la creación de nuevos componentes, la consolidación de los existentes o la separación de los mismos porque tienen demasiada responsabilidad.
• Analyze Roles and Responsibilities: Pensar tanto en los roles y responsabilidades que la aplicación debe soportar para descubrir la granularidad correcta de los componentes.
• Analyze Architecture Characteristics: Mientras se asignan los requisitos funcionales a los componentes también se debe observar las características arquitectónicas descubiertas anteriormente. La idea es pensar en cómo las características arquitectónicas podrían afectar a la división y granularidad de los componentes. Por ejemplo, mientras que una parte del sistema pueden ocuparse de la entrada del usuario, la parte que trata con ciento de usuarios concurrentes necesitará diferentes caraterísticas arquitectónicas a diferencia de la otra parte.
• Restructure Components: Los arquitectos deben iterar continuamente en su diseño de componentes con ayuda de los desarrolladores. A medida que los desarrolladores profundizan en la construcción de la aplicación, se adquiere una comprensión más matizada de dónde deben estar el comportamiento y los roles.

Enlaces:

• Fundamentals of Software Architecture - Neal Ford, Mark Richards
• Arquitectura de software. Conceptos y ciclo de desarrollo - Humberto Cervantes Maceda