Patrones de arquitectura vs. Patrones de diseño

La RAE (Real academia española) cita: 

* Patrón: Modelo que sirve de muestra para sacar otra cosa igual.

Patrón de diseño:

Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software. En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del problema) y las consecuencias (costos y beneficios). 

Los patrones de diseño facilitan la reutilización de arquitecturas y diseños de software exitosos.

Patrón de arquitectura:

Son patrones de diseño de software que ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones arquitectónicos tienen una nivel de abstracción mayor.

Si queremos creer que realmente existe diferencia, entonces es fácil verla midiendo el impacto al aplicar el patrón: si este es relevante a la totalidad del sistema entonces hablamos de un patrón de arquitectura; en cambio, si este sólo concierne a un subcomponente, nos referimos a un patrón de diseño.

Tomen como caso el patrón de Layers , este es claramente un patrón arquitectónico, ya que concierne al diseño general de la aplicación. Mientras que el patrón Active Record , que lidia con los mecanismos de persistencia de datos es un patrón de diseño.

Pero, qué pasa cuando lo que era totalidad se vuelve un subcomponente?. Cambiarían entonces sus patrones de arquitectura a diseño?. Aquí es donde no es tan fácil la respuesta.

Hay otros patrones que solapan responsabilidades de todo-parte, por ejemplo el MVC . Según como se aplique puede ser un patrón de diseño o arquitectura.