Posts

El objetivo de la arquitectura de software es mnimizar los recursos humanos necesarios para construir y mantener un sistema. Single Responsability. Open-Closed Principle. Liskov Substitution Principle. Interface Segregation Principle. Dependency Inversion Principle. Estos principios nos ayudarán a: Crear software escalable. Crear una arquitectura limpia y mantenible. Escribir código más fácil de leer y entendible. Módulos con alta cohesión y bajo acoplamiento. 1. Single Responsability Principle Un módulo debe tener una única razón para cambiar, es decir, que solo debe ser responsable de un usuario, de ninguno más....

Hoy hablaré de los microservicios, que son, para que sirven y pros y contras. ¿Qué son? La arquitectura de microservicios proporciona una serie de prácticas, organización de trabajo y de equipos para construir software complejo de forma más eficiente, rápida y a gran escala. Esto es así debido a que la aplicación es un conjunto de servicios pequeños e independientes en el que cada uno se centra en una tarea específica y se comunica con otros servicios a través de interfaces bien definidas....

Partición de equivalencias Los datos de entrada de un programa se pueden agrupar en clases diferentes en las que todos los miembros de dicha clase están relacionados. Cada una de estas clases es una partición de equivalencia en la que el programa se comporta de la misma forma para cada miembro de la clase. Esto nos permite reducir así el número total de casos de prueba que hay que desarrollar. Consta de dos pasos:...

Realizar commits atómicos El enfoque atómico supone lo siguiente. Confirmar (commitear) cada modificación o tarea como un cambio separado. Confirmar solo cuando se complete un bloque de trabajo. Confirmar cada cambio de diseño por separado, con confirmación conjunta para: archivos de diseño, código subyacente y recursos adicionales. Beneficios del enfoque atómico Es fácil de revertir un commit sin afectar a otros cambios. Es fácil hacer otros cambios sobre la marcha....

Es un vocabulario común que describe el dominio del problema utilizado por todas las personas implicadas en el proyecto para evitar malentendidos. Se crea a partir de sesiones de brainstorming y análisis de dominio. Debe ser documentado y actualizado durante todo el transcurso del proyecto debe ser claro y sobre todo lo menos ambiguo posible. El lenguaje ubicuo evoluciona según vamos aprendiendo más sobre el dominio. Debe ser utilizado siempre, en todas las conversaciones....

Empezaremos por ver las diferencias entre una arquitectura centrada en datos y otra en el dominio. Arquitectura centrada en los datos ❌ Se piensa primero en los datos que se necesitan almacenar. Se recopilan requisitos para tener claras las reglas de negocio. Diseño del modelo de datos. Diseñamos y construimos nuestro sistema para trabajar con los datos. Como consecuencia, tenemos una arquitectura de software totalmente dependiente de los datos. Arquitectura centrada en el dominio ✅ Se piensa en el dominio del problema (lógica central es decir enfocarnos en todas las cosas importantes relacionada con el área del problema que queremos tratar) no en los datos que se necesitan almacenar....

Es una plataforma streaming distribuida que permite a los desarrolladores enviar y recibir mensajes de manera eficiente y confiable a través de aplicaciones. Es escalable, tolerante a fallos y de alto rendimiento lo que lo hace ideal para aplicaciones en tiempo real y procesamiento de datos en grandes volúmenes. Sin Kafka Con Kafka Características Permite publicar y subscribirse a flujos de datos (streams) de manera distribuida. Almacena flujos de datos de manera persistente y tolerante a fallos....