<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cyb3rh4ck D3v L1f3</title><link>https://cyb3rh4ck.github.io/</link><description>Recent content on Cyb3rh4ck D3v L1f3</description><generator>Hugo</generator><language>es</language><lastBuildDate>Sat, 03 Oct 2026 09:00:00 -0600</lastBuildDate><atom:link href="https://cyb3rh4ck.github.io/index.xml" rel="self" type="application/rss+xml"/><item><title>PhysiqueOS: Case Study de Arquitectura de un Modular Monolith</title><link>https://cyb3rh4ck.github.io/post/physiqueos-architecture-case-study/</link><pubDate>Sat, 03 Oct 2026 09:00:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/physiqueos-architecture-case-study/</guid><description>Cómo diseñé PhysiqueOS, una app para registrar entrenamientos de fuerza: modular monolith, límites por módulo de negocio, concurrencia optimista, snapshots inmutables y una estrategia de pruebas con PostgreSQL real.</description></item><item><title>Vertical and Horizontal Scaling: Estrategias Fundamentales</title><link>https://cyb3rh4ck.github.io/post/vertical-horizontal-scaling/</link><pubDate>Mon, 06 Apr 2026 11:10:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/vertical-horizontal-scaling/</guid><description>Una guía técnica para entender cuándo hacer scaling up (mejorar hardware) o scaling out (agregar servidores), preparando el camino hacia la arquitectura monolítica y distribuida.</description></item><item><title>Overview de los Architectural Styles más comunes</title><link>https://cyb3rh4ck.github.io/post/overview-of-architectural-styles/</link><pubDate>Mon, 06 Apr 2026 10:52:20 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/overview-of-architectural-styles/</guid><description>&lt;p&gt;En el &lt;em&gt;software development&lt;/em&gt; (desarrollo de software), los &lt;em&gt;architectural styles&lt;/em&gt; (estilos arquitectónicos) son cruciales para determinar cómo se estructuran y cómo funcionarán los sistemas. Cada &lt;em&gt;architectural style&lt;/em&gt; tiene su propio conjunto de principios y patrones que abordan problemas y requisitos específicos. Seleccionar un &lt;em&gt;software architectural style&lt;/em&gt; es una decisión crítica en el proceso de desarrollo de software, ya que impacta el &lt;em&gt;performance&lt;/em&gt; (rendimiento), la &lt;em&gt;maintainability&lt;/em&gt; (mantenibilidad), la &lt;em&gt;scalability&lt;/em&gt; (escalabilidad) y el éxito general de la aplicación.&lt;/p&gt;</description></item><item><title>README</title><link>https://cyb3rh4ck.github.io/readme/</link><pubDate>Fri, 03 Apr 2026 00:00:00 +0000</pubDate><guid>https://cyb3rh4ck.github.io/readme/</guid><description>&lt;h1 id="cyb3rh4ck-"&gt;Cyb3rh4ck 💻⚡&lt;/h1&gt;&#10;&lt;p&gt;&lt;strong&gt;Software Architect | Senior Backend Engineer | System Designer&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;No me limito a escribir código; &lt;strong&gt;diseño y construyo sistemas distribuidos, escalables y a prueba de balas&lt;/strong&gt;. Mi dominio es el backend profundo: allí donde la lógica de negocio compleja exige soluciones de ingeniería precisas, resilientes y de alto rendimiento. Construyo los sistemas que mantienen las cosas funcionando cuando todo lo demás falla.&lt;/p&gt;&#10;&lt;h3 id="-arsenal-técnico-clásico-y-avanzado"&gt;⚙️ Arsenal Técnico Clásico y Avanzado&lt;/h3&gt;&#10;&lt;ul&gt;&#10;&lt;li&gt;&lt;strong&gt;Arquitectura y Diseño:&lt;/strong&gt; Arquitectura Hexagonal (Ports &amp;amp; Adapters), Clean Architecture y Microservicios Event-Driven. Aplicación quirúrgica y estricta de principios &lt;strong&gt;SOLID&lt;/strong&gt;, alta cohesión y bajo acoplamiento.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Core Backend:&lt;/strong&gt; Dominio de &lt;strong&gt;Java 21+&lt;/strong&gt;, el ecosistema &lt;strong&gt;Spring Boot&lt;/strong&gt;, Spring Data JPA e Hibernate.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Sistemas Asíncronos y Distribuidos:&lt;/strong&gt; Mensajería de alta disponibilidad con &lt;strong&gt;Apache Kafka&lt;/strong&gt;. Implementación rigurosa de patrones de resiliencia y consistencia eventualmente distribuida como &lt;strong&gt;Transactional Outbox&lt;/strong&gt;, CQRS y Sagas.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Patrones de Software:&lt;/strong&gt; Maestría en patrones de diseño orientados a la creación (Factories, Builders) y estructuración de sistemas complejos, priorizando siempre la legibilidad y la escalabilidad del dominio.&lt;/li&gt;&#10;&lt;/ul&gt;&#10;&lt;h3 id="-manifiesto-de-ingeniería"&gt;🛡️ Manifiesto de Ingeniería&lt;/h3&gt;&#10;&lt;ol&gt;&#10;&lt;li&gt;&lt;strong&gt;La Calidad no es negociable:&lt;/strong&gt; El código se lee cien veces más de lo que se escribe. Desarrollo para el futuro, garantizando mantenibilidad desde el commit inicial.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Resiliencia por Diseño:&lt;/strong&gt; Asumo que el sistema fallará. Mis arquitecturas están diseñadas para la recuperación automática, mitigación de desastres y la preservación absoluta de la consistencia de los datos.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Simplicidad sobre Complejidad Accidental:&lt;/strong&gt; Diseño sistemas simples para resolver problemas complejos. La abstracción solo se introduce cuando está justificada.&lt;/li&gt;&#10;&lt;li&gt;&lt;strong&gt;Simbiosis con la Inteligencia Artificial:&lt;/strong&gt; No busco competir contra la IA; la utilizo como un &lt;strong&gt;multiplicador de fuerza extrema&lt;/strong&gt; y un exoesqueleto cognitivo. Herramientas como GitHub Copilot, Claude Code y la orquestación de Agentes Autónomos no me desplazan: automatizan lo predictivo y potencian exponencialmente mi capacidad y velocidad, permitiéndome enfocar mi impacto exclusivamente en el diseño complejo y la arquitectura pura.&lt;/li&gt;&#10;&lt;/ol&gt;&#10;&lt;blockquote&gt;&#10;&lt;p&gt;&lt;em&gt;&amp;ldquo;Café, Código y Spring Boot.&amp;rdquo;&lt;/em&gt; — El código temporal se reescribe; una arquitectura impecable trasciende.&lt;/p&gt;&#10;&lt;/blockquote&gt;</description></item><item><title>Implementando los Principios SOLID (y Reglas de Oro)</title><link>https://cyb3rh4ck.github.io/post/implementing-solid-principles/</link><pubDate>Tue, 31 Mar 2026 12:55:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/implementing-solid-principles/</guid><description>Explora uno a uno los 5 principios SOLID y otras reglas fundamentales de la comunidad para construir software limpio, mantenible y verdaderamente flexible.</description></item><item><title>Principios de Arquitectura de Software: Entendiendo la Cohesion y el SoC</title><link>https://cyb3rh4ck.github.io/post/cohesion-and-separation-of-concerns/</link><pubDate>Tue, 31 Mar 2026 11:58:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/cohesion-and-separation-of-concerns/</guid><description>Aprende qué es la Cohesion en el desarrollo de software, por qué es crucial, y cómo el principio SoC te ayuda a construir componentes más robustos.</description></item><item><title>Principios de Arquitectura de Software: Explorando el Coupling</title><link>https://cyb3rh4ck.github.io/post/principles-of-software-architecture/</link><pubDate>Tue, 31 Mar 2026 10:30:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/principles-of-software-architecture/</guid><description>Aprende qué es el coupling, por qué es crucial mantenerlo bajo y cómo implementarlo utilizando interfaces en Java para mejorar el diseño de tu sistema.</description></item><item><title>La Relevancia de SOLID (Traducción)</title><link>https://cyb3rh4ck.github.io/post/solid-relevance/</link><pubDate>Sat, 28 Mar 2026 21:42:00 -0600</pubDate><guid>https://cyb3rh4ck.github.io/post/solid-relevance/</guid><description>&lt;blockquote&gt;&#10;&lt;p&gt;&lt;strong&gt;Nota:&lt;/strong&gt; Esta es una traducción fiel al español (latino) del artículo original &lt;a href="https://blog.cleancoder.com/uncle-bob/2020/10/18/Solid-Relevance.html"&gt;&amp;ldquo;Solid Relevance&amp;rdquo;&lt;/a&gt; escrito por Robert C. Martin (Uncle Bob).&lt;/p&gt;&#10;&lt;/blockquote&gt;&#10;&lt;p&gt;Recientemente recibí una carta de alguien con una inquietud. Decía lo siguiente:&lt;/p&gt;&#10;&lt;blockquote&gt;&#10;&lt;p&gt;Durante años, el conocimiento de los principios SOLID ha sido una parte estándar de nuestro procedimiento de contratación. Se esperaba que los candidatos tuvieran un buen conocimiento práctico de estos principios. Sin embargo, últimamente, uno de nuestros gerentes, que ya no programa mucho, ha cuestionado si eso es sensato. Sus puntos fueron que el principio Abierto-Cerrado (Open-Closed) ya no es muy importante porque la mayor parte del código que escribimos no está contenido en grandes monolitos y hacer cambios en pequeños microservicios es seguro y fácil. El Principio de Sustitución de Liskov está muy desactualizado porque ya no nos enfocamos tanto en la herencia como lo hacíamos hace 20 años. Creo que deberíamos considerar &lt;a href="https://speakerdeck.com/tastapod/why-every-element-of-solid-is-wrong"&gt;la postura de Dan North sobre SOLID&lt;/a&gt;: &amp;ldquo;Simplemente escribe código simple&amp;rdquo;.&lt;/p&gt;&#10;&lt;/blockquote&gt;</description></item></channel></rss>