Tech Lead compartiendo ideas prácticas sobre artesanía del software, TDD, liderazgo, Bitcoin e IA. Artículos, resúmenes de libros y charlas.Zola2020-09-10T00:00:00+00:00https://chemaclass.com/es/tags/ddd/atom.xmlDDD explicado de forma clara y práctica2020-09-10T00:00:00+00:002020-09-10T00:00:00+00:00 Vaughn Vernonhttps://chemaclass.com/es/readings/domain-driven-design-distilled/

Una introducción accesible a DDD para desarrolladores, consultores y cualquiera que quiera entender el diseño guiado por dominio

<p>Este libro hace que DDD cobre vida. Da igual si eres desarrollador, consultor o cliente: te ayuda a entenderlo y sacarle provecho.</p> <span id="continue-reading"></span> <hr /> <p>Desarrolladores de todo el mundo lo están adoptando porque da resultados reales. Es una guía accesible que responde:</p> <ul> <li>¿Qué es DDD?</li> <li>¿Qué problemas resuelve?</li> <li>¿Cómo funciona?</li> <li>¿Cómo sacarle valor rápido?</li> </ul> <p>Aprenderás a separar modelos de dominio con <strong>Contextos Acotados</strong> (Bounded Contexts), a desarrollar un <strong>Lenguaje Ubicuo</strong> dentro de cada contexto, y a lograr que <strong>expertos de dominio</strong> y <strong>desarrolladores</strong> colaboren para crear ese lenguaje.</p> <p>También cubre cómo usar Subdominios para manejar sistemas legacy e integrar varios Contextos Acotados definiendo relaciones entre equipos.</p> <blockquote> <p>Domain-Driven Design Distilled da vida a <strong>DDD</strong>.</p> </blockquote>Guía del artesano para la estructura y diseño de software2018-06-04T00:00:00+00:002018-06-04T00:00:00+00:00 Robert C. Martinhttps://chemaclass.com/es/readings/clean-architecture/

Cómo estructurar y diseñar software de forma profesional. Principios SOLID, componentes y capas explicados con claridad.

<span id="continue-reading"></span><h3 id="principios-de-diseno-de-codigo-solid">Principios de diseño de código (SOLID) <a class="heading-anchor" href="#principios-de-diseno-de-codigo-solid" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li><strong>Responsabilidad Única</strong>: una clase debe tener una sola razón para cambiar. O en su versión nueva: un módulo responde ante un solo actor.</li> <li><strong>Abierto-cerrado</strong>: abierta para extensión, cerrada para modificación.</li> <li><strong>Sustitución de Liskov</strong>: puedes reemplazar objetos por instancias de sus subtipos sin romper el programa.</li> <li><strong>Segregación de Interfaces</strong>: mejor muchas interfaces específicas que una general.</li> <li><strong>Inversión de Dependencias</strong>: depende de abstracciones, no de implementaciones concretas.</li> </ul> <h3 id="principios-de-componentes">Principios de componentes <a class="heading-anchor" href="#principios-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h3> <h4 id="cohesion-de-componentes">Cohesión de componentes <a class="heading-anchor" href="#cohesion-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h4> <ul> <li><strong>Equivalencia Reutilización/Liberación</strong>: las clases reutilizadas juntas deben liberarse juntas. Mismo número de versión y changelog adecuado.</li> <li><strong>Cierre Común</strong>: las clases que cambian juntas van juntas. Es el principio de responsabilidad única a nivel de componente.</li> <li><strong>Reutilización Común</strong>: no obligues a los usuarios a depender de lo que no necesitan. Segregación de interfaces a nivel de componente.</li> </ul> <h4 id="acoplamiento-de-componentes">Acoplamiento de componentes <a class="heading-anchor" href="#acoplamiento-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h4> <ul> <li><strong>Dependencias Acíclicas</strong>: sin ciclos en el grafo de dependencias. Los ciclos fuerzan a liberar componentes juntos. Usa inversión de dependencias para romperlos.</li> <li><strong>Dependencia Estable</strong>: los componentes menos estables dependen de los más estables. Depende en dirección de la estabilidad.</li> <li><strong>Abstracciones Estables</strong>: los componentes estables deben ser abstractos. Ejemplo: una política de alto nivel que se extiende siguiendo abierto-cerrado.</li> </ul> <h3 id="principios-de-arquitectura">Principios de arquitectura <a class="heading-anchor" href="#principios-de-arquitectura" title="Copy link" aria-label="Link to this section">#</a> </h3> <h4 id="estableciendo-limites">Estableciendo límites <a class="heading-anchor" href="#estableciendo-limites" title="Copy link" aria-label="Link to this section">#</a> </h4> <p>Los límites separan elementos de software: lo que importa de lo que no, lo de alto nivel de lo de bajo nivel. Si el código de alto nivel depende del de bajo nivel, los cambios se propagan hacia arriba. Ponemos un límite usando polimorfismo para invertir el flujo. Esto es el Principio de Inversión de Dependencias de SOLID.</p> <h4 id="separando-capas">Separando capas <a class="heading-anchor" href="#separando-capas" title="Copy link" aria-label="Link to this section">#</a> </h4> <p>Cuatro capas principales (aunque puede variar):</p> <ul> <li><strong>Entidades</strong>: objetos con lógica de negocio crítica. Ejemplo: un banco que no da préstamos a clientes sin cierta puntuación crediticia. Se comparten entre aplicaciones de la empresa.</li> <li><strong>Casos de uso</strong>: reglas de negocio específicas de la aplicación. Ejemplo: la secuencia de pantallas para hacer una transferencia.</li> <li><strong>Adaptadores de interfaz</strong>: gateways, presenters, controllers. Aquí va la arquitectura MVC de la GUI y la transformación de datos entre base de datos y casos de uso.</li> <li><strong>Frameworks y drivers</strong>: frameworks web, base de datos, la vista de MVC.</li> </ul>