<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Arquitectura on metroSetenta</title>
    <link>https://metrosetenta.es/tags/arquitectura/</link>
    <description>Recent content in Arquitectura on metroSetenta</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 19 Aug 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://metrosetenta.es/tags/arquitectura/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Las tres categorías de estructuras de una arquitectura de software</title>
      <link>https://metrosetenta.es/blog/las-tres-categorias-de-estructuras-de-una-arquitectura-de-software/</link>
      <pubDate>Wed, 19 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://metrosetenta.es/blog/las-tres-categorias-de-estructuras-de-una-arquitectura-de-software/</guid>
      <description>&lt;p&gt;Cuando empecé a estudiar arquitectura de software, una de las cosas que más me costaba era entender qué significaba exactamente cada una de las cajas que aparecían en los diagramas. Una caja podía representar un módulo, un componente, un servicio, un proceso o incluso un servidor. Con las flechas ocurría algo parecido: podían representar una dependencia, una llamada, un mensaje o una relación entre el software y la infraestructura.&lt;/p&gt;&#xA;&lt;p&gt;Después de leer &lt;em&gt;Software Architecture in Practice&lt;/em&gt;, de Len Bass, Paul Clements y Rick Kazman, encontré una clasificación que me resulta bastante útil para poner un poco de orden en todo esto. Los autores hablan de tres categorías de estructuras arquitectónicas: &lt;strong&gt;estructuras de módulos, estructuras de componentes y conectores y estructuras de asignación&lt;/strong&gt;.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
