[{"data":1,"prerenderedAt":67},["ShallowReactive",2],{"article-la-importancia-de-tener-una-buena-arquitectura-de-software":3},{"editorial_managed":4,"editorial_preview":5,"editorial_type":6,"title":7,"slug":8,"href":9,"description":10,"category":11,"category_slug":12,"author":13,"date":14,"updated_at":15,"read_time":16,"cover_image":17,"cover_alt":18,"cover_width":19,"cover_height":20,"cover_small":18,"social_alt":18,"preview_image":17,"social_image":17,"social_width":19,"social_height":20,"social_type":21,"seo_title":7,"seo_description":10,"html":22,"toc":23,"related":39,"tags":56},true,false,"Explicación","Qué decisiones resuelve la arquitectura de software","la-importancia-de-tener-una-buena-arquitectura-de-software","\u002Fes-mx\u002Frecursos\u002Fla-importancia-de-tener-una-buena-arquitectura-de-software","Entiende qué decisiones resuelve la arquitectura de software sobre componentes, datos y dependencias para organizar un sistema que pueda evolucionar.","Desarrollo de software","desarrollo-de-software","Acinsoft","2023-04-02 11:30:15","2026-09-17 00:00:00",3,"\u002Fimages\u002Feditorial-20260913\u002F068-social.jpg","",1200,630,"image\u002Fjpeg","\u003Cp class=\"lead\">La arquitectura de software organiza componentes, datos y dependencias para que el sistema pueda cumplir su función y cambiar con un costo razonable. No es una lista de tecnologías ni un diagrama lleno de servicios.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-1\">Decisiones que sí importan al negocio\u003C\u002Fh2>\u003Cul>\u003Cli>Dónde se conserva la información principal.\u003C\u002Fli>\u003Cli>Qué parte puede cambiar sin rehacer las demás.\u003C\u002Fli>\u003Cli>Qué sucede cuando una dependencia falla.\u003C\u002Fli>\u003Cli>Cómo se observa y se entrega una nueva versión.\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Microsoft incluye operación, evolución y necesidades del negocio entre sus principios de arquitectura. La utilidad está en relacionar cada decisión con una necesidad, no en incorporar todas las técnicas descritas. \u003Ca href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fazure\u002Farchitecture\u002Fguide\u002Fdesign-principles\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Principios de arquitectura\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-2\">Un ejemplo para discutir\u003C\u002Fh2>\u003Cp>Ejemplo hipotético: un portal consulta datos de pedidos y envía notificaciones. Si el servicio de correo falla, quizá el pedido deba seguir registrándose y el aviso quedar pendiente. Esa regla influye en cómo se separan componentes y se controla su estado.\u003C\u002Fp>\u003Cp>El diseño debe indicar cómo se detecta el pendiente y quién lo revisa. Dibujar una flecha entre dos cajas no resuelve ese comportamiento.\u003C\u002Fp>\n\u003Ch2 id=\"articulo-seccion-3\">Complejidad con una razón\u003C\u002Fh2>\u003Cp>Separar todo en muchos servicios puede añadir despliegues, comunicación y seguimiento. Mantenerlo todo unido también tiene consecuencias cuando distintas partes crecen o cambian de forma independiente. La elección depende del contexto y de la capacidad de operación.\u003C\u002Fp>\u003Cp>Pide una explicación de las alternativas descartadas y de los riesgos aceptados. Para un proyecto pequeño, una estructura sencilla y bien documentada puede ser suficiente.\u003C\u002Fp>\u003Cp>Una revisión útil termina con decisiones comprensibles: qué se conserva, qué puede evolucionar y qué escenario requiere otra inversión. No hace falta que el propietario conozca cada tecnología para entender esas consecuencias.\u003C\u002Fp>\n\n\u003Ch2 id=\"articulo-seccion-4\">Un pedido que debe conservarse aunque falle el aviso\u003C\u002Fh2>\u003Cfigure class=\"flow\">\u003Cdiv>Portal: recibe una solicitud válida\u003C\u002Fdiv>\u003Cspan aria-hidden=\"true\">↓\u003C\u002Fspan>\u003Cdiv>Aplicación y datos: conservan el pedido y su estado\u003C\u002Fdiv>\u003Cspan aria-hidden=\"true\">↓\u003C\u002Fspan>\u003Cdiv>Notificación: registra envío logrado o pendiente\u003C\u002Fdiv>\u003Cspan aria-hidden=\"true\">↓\u003C\u002Fspan>\u003Cdiv>Operación: localiza y atiende los pendientes\u003C\u002Fdiv>\u003Cfigcaption>Arquitectura conceptual, no infraestructura implementada ni garantía de entrega.\u003C\u002Ffigcaption>\u003C\u002Ffigure>\u003Cp>La pregunta decisiva es cuándo se considera aceptado el pedido. Si el correo falla después de guardarlo, el usuario no debería interpretar automáticamente que debe crearlo otra vez. Acuerda la regla y cómo consultar el estado; después el equipo elige mecanismos compatibles con ella. Una flecha adicional no resuelve por sí sola duplicados o fallos.\u003C\u002Fp>\n\u003Cp>Para profundizar en las tareas relacionadas: \u003Ca href=\"\u002Fes-mx\u002Frecursos\u002Fintroduccion-a-las-api-y-su-papel-en-la-integracion-de-sistemas\" rel=\"noopener noreferrer\">Qué es una API y cómo conecta sistemas\u003C\u002Fa>; \u003Ca href=\"\u002Fes-mx\u002Frecursos\u002Fcomo-garantizar-la-escalabilidad-de-tus-aplicaciones-y-sistemas-erp\" rel=\"noopener noreferrer\">Cómo planear el crecimiento de un sistema\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cdiv class=\"cta\">\u003Ch2 id=\"articulo-seccion-5\">¿Hay un proceso que necesitas mejorar?\u003C\u002Fh2>\u003Cp>Cuéntanos qué ocurre hoy y qué resultado buscas. Podemos revisar una primera etapa para desarrollar o integrar la solución.\u003C\u002Fp>\u003Ca href=\"\u002Fes-mx\u002Fservicios\u002Fdesarrollo-software\" rel=\"noopener noreferrer\">Explorar desarrollo de software\u003C\u002Fa>\u003C\u002Fdiv>\n",[24,27,30,33,36],{"id":25,"title":26},"articulo-seccion-1","Decisiones que sí importan al negocio",{"id":28,"title":29},"articulo-seccion-2","Un ejemplo para discutir",{"id":31,"title":32},"articulo-seccion-3","Complejidad con una razón",{"id":34,"title":35},"articulo-seccion-4","Un pedido que debe conservarse aunque falle el aviso",{"id":37,"title":38},"articulo-seccion-5","¿Hay un proceso que necesitas mejorar?",[40,48],{"editorial_managed":4,"editorial_preview":5,"editorial_type":41,"title":42,"slug":43,"href":44,"description":45,"category":11,"category_slug":12,"author":13,"date":46,"updated_at":15,"read_time":16,"cover_image":47,"cover_alt":18,"cover_width":19,"cover_height":20,"cover_small":18,"social_alt":18,"preview_image":47,"social_image":47,"social_width":19,"social_height":20,"social_type":21,"seo_title":42,"seo_description":45},"Guía de decisión","Framework o código propio: cómo decidir","frameworks-o-codigo-puro-mirada-al-desarrollo-web-frontend-y-backend","\u002Fes-mx\u002Frecursos\u002Fframeworks-o-codigo-puro-mirada-al-desarrollo-web-frontend-y-backend","Compara utilizar un framework con desarrollar componentes propios, considerando convenciones, dependencias y el trabajo de mantenimiento del proyecto.","2024-09-23 22:48:08","\u002Fimages\u002Feditorial-20260913\u002F049-social.jpg",{"editorial_managed":4,"editorial_preview":5,"editorial_type":6,"title":49,"slug":50,"href":51,"description":52,"category":11,"category_slug":12,"author":13,"date":53,"updated_at":15,"read_time":54,"cover_image":55,"cover_alt":18,"cover_width":19,"cover_height":20,"cover_small":18,"social_alt":18,"preview_image":55,"social_image":55,"social_width":19,"social_height":20,"social_type":21,"seo_title":49,"seo_description":52},"Qué cambia al coordinar desarrollo y operación","uso-de-la-metodologia-devops-para-mejorar-la-colaboracion-en-el-desarrollo-de-software","\u002Fes-mx\u002Frecursos\u002Fuso-de-la-metodologia-devops-para-mejorar-la-colaboracion-en-el-desarrollo-de-software","Conoce qué cambia al coordinar desarrollo y operación para que cada mejora esté preparada para instalarse, observarse y mantenerse en funcionamiento.","2023-04-06 05:33:19",2,"\u002Fimages\u002Feditorial-20260913\u002F088-social.jpg",[57,60,63,65],{"name":58,"slug":59},"arquitectura de software","arquitectura-de-software",{"name":61,"slug":62},"calidad de software","calidad-de-software",{"name":64,"slug":64},"escalabilidad",{"name":66,"slug":66},"mantenibilidad",1791093714117]