DEV Community: Nicolás Azuaga

🧩 Diseño y Modelado: ¿son lo mismo?

Nicolás Azuaga — Mon, 04 Aug 2025 12:50:02 +0000

¿A qué nos referimos cuando hablamos de diseño en desarrollo de software?

Cuando hablamos de diseño en el desarrollo de software, no nos referimos a dibujar interfaces o hacer diagramas bonitos. En este contexto, diseñar es programar.

El diseño se manifiesta en cómo estructuramos el código, cómo distribuimos responsabilidades, cómo nombramos, cómo pensamos en la mantenibilidad, la extensibilidad y la claridad del sistema.

Pero también incluye decisiones más amplias como cómo estructuramos el proyecto, cómo organizamos carpetas, módulos y dependencias.

Entonces... ¿qué es modelar?

El modelado tiene que ver con representar el dominio del problema. Es la forma en que interpretamos y trasladamos el mundo real —o una parte de él— a estructuras que puede entender una máquina.

Modelar es preguntarse:

“¿Cómo represento estos conceptos, reglas y comportamientos en código?”

Mientras que el diseño se enfoca en cómo se organizan esas piezas técnicas, el modelado se enfoca en qué piezas existen y por qué.

¿Diseño y modelado son lo mismo?

No. Pero están profundamente conectados.

Podés tener un buen diseño de software (organizado, limpio, flexible), pero si el modelo no representa bien el dominio, el sistema va a fallar en su propósito.

Y al revés: podés tener un modelo que entiende bien el negocio, pero con un diseño pobre que lo vuelve difícil de mantener o escalar.

Diseño y modelado trabajan juntos.

Uno apunta a la forma y el otro al contenido. Uno se preocupa por la estructura técnica, el otro por el significado del sistema.

¿Qué es un modelo?

Un modelo es una representación simplificada de la realidad. Como todo modelo, omite ciertos detalles para enfocarse en lo esencial.

Una buena forma de entenderlo es con este ejemplo:

El dibujo es un modelo: representa los elementos más importantes (puerta, ventanas, techo), pero deja de lado muchos detalles (materiales, instalaciones eléctricas, muebles).

Ese dibujo es útil porque nos permite trabajar con una abstracción comprensible, sin tener que lidiar con la complejidad completa del objeto real.

Tipos de modelos

En el desarrollo de software, usamos distintos modelos según la capa en la que estemos trabajando (hablaremos de las capas más adelante). Algunos ejemplos:

Modelo de Dominio

Representa los conceptos, reglas y comportamientos de elementos del mundo real, según el problema que queremos resolver.

Está enfocado en la lógica del negocio o del juego, y es independiente de cómo se almacenan o se muestran los datos.

Ejemplos (en el contexto de Pokémon):

Entrenador: puede capturar Pokémon, tiene un equipo limitado a 6.
Pokemon: gana experiencia, sube de nivel, puede evolucionar.
Mochila: guarda objetos con capacidad limitada.
Batalla: gestiona el combate entre dos Pokémon.

Este modelo contiene la verdadera lógica del sistema. Si el juego cambiara de plataforma (de consola a web, por ejemplo), este modelo debería seguir funcionando sin cambios.

Según el problema (dominio o contexto) que estemos modelando —o resolviendo—, nuestros objetos serán representaciones lógicas de esa realidad.

Modelo de Datos

Representa cómo se persisten esos datos, por ejemplo, en una base de datos, en memoria, en un archivo, etc.

Puede incluir detalles técnicos como IDs, timestamps o claves foráneas.

Ejemplo: una tabla SQL o un DTO (Data Transfer Object).

Modelo de Vista (ViewModel)

Así como un dibujo simplifica una casa para mostrar solo lo esencial, un ViewModel simplifica y estructura los datos necesarios para representar una vista de una interfaz de usuario.

No es la vista en sí (no tiene estilos ni comportamiento visual), pero sí es un modelo de esa vista: una abstracción que representa únicamente lo importante para mostrar en pantalla —texto, imágenes, contadores, acciones, etc.

Si la interfaz de usuario representa la realidad (la casa), el ViewModel será una simplificación de esa realidad (el dibujo de la casa), lo que permite manejar mejor la complejidad al trabajar con ella.

Ejemplo:

Vista

Modelo

Cada modelo cumple un propósito distinto.

Confundirlos o mezclarlos suele llevar a problemas de acoplamiento y dificultad para evolucionar el sistema.

Profundicemos un poco más en el diseño

Diseñar software es tomar decisiones sobre cómo estructuramos el sistema para que sea comprensible, flexible y fácil de mantener.

En el frontend, esto incluye preguntas como:

¿Dónde pongo la lógica?
¿Cómo divido mis componentes?
¿Cómo evito que los cambios en un lugar rompan todo lo demás?
¿Qué depende de qué? ¿Qué debería saber cada módulo?
¿Cómo organizo la estructura del proyecto, carpetas y archivos?

Un buen diseño reduce el costo del cambio. Te permite agregar nuevas funcionalidades sin miedo a romper cosas. Hace que otros puedan leer tu código y entender qué hace. Y, sobre todo, hace que el software evolucione sin volverse un caos.

No existe un único “buen diseño”, pero sí hay principios que nos ayudan a evaluarlo:

Un buen diseño debe tener una Alta Cohesión y un Bajo Acoplamiento

Acoplamiento

El acoplamiento describe el grado de dependencia entre módulos.
Cuando un módulo está fuertemente acoplado a otros, necesita conocer demasiado sobre su estructura o comportamiento. Esto genera un sistema frágil, donde un cambio en un lugar puede afectar múltiples partes no relacionadas.

En cambio, con bajo acoplamiento, los módulos mantienen vínculos débiles entre sí. Esto significa que se relacionan de forma superficial, sin depender fuertemente uno del otro. Cada módulo puede cambiar o evolucionar sin arrastrar al resto.

Reducir el acoplamiento innecesario permite que el sistema sea más flexible, fácil de modificar y menos propenso a errores en cascada.

Cohesión

La cohesión se refiere a qué tan enfocada está una pieza de código en cumplir una única responsabilidad. Además, a nivel semántico, todos sus componentes deben estar relacionados entre sí.
Por ejemplo, un módulo de pagos debería contener únicamente lo relacionado con pagos. No tendría sentido que incluya lógica sobre cobros u otros conceptos que diluyen la intención del módulo.
Cuando todo está relacionado de forma coherente, el código es más fácil de entender y mantener.

Un módulo con alta cohesión tiene todas sus funciones alineadas con un propósito claro y específico.
Esto mejora la legibilidad, el mantenimiento y las pruebas. En cambio, un módulo con responsabilidades mezcladas tiende a volverse confuso, frágil y difícil de extender.

Diseñar bien implica buscar bajo acoplamiento y alta cohesión en todo el sistema.

Ejemplos

Sistemas con Baja Cohesión y Bajo Acoplamiento

En este tipo de sistemas, los módulos no están fuertemente conectados entre sí —lo cual parece positivo—, pero internamente cada módulo carece de coherencia: hacen muchas cosas distintas que no están claramente relacionadas.

Esto dificulta el mantenimiento, ya que no queda claro qué hace cada módulo ni dónde debería ir cierta funcionalidad.
El resultado es un sistema desorganizado, disperso y difícil de entender.

Sistemas con Alta Cohesión y Alto Acoplamiento

En estos sistemas, todo está en un solo lugar: hay una única pieza que concentra muchas responsabilidades.
Podemos decir que hay alta cohesión, porque las partes están alineadas semánticamente y sabemos claramente qué hace el módulo.

Pero al mismo tiempo, está todo tan interconectado internamente, con tantos vínculos fuertes entre componentes, que cualquier cambio puede tener efectos colaterales no deseados.

Además, como una sola unidad controla muchas cosas, el sistema depende demasiado de ese módulo central, lo que genera alto acoplamiento.
Esto vuelve al sistema difícil de mantener, de testear y de escalar, incluso si su organización interna parece clara.

El Ideal

sistemas con Bajo Acoplamiento y Alta Cohesión

Esto es lo que buscamos cuando intentamos construir un software bien diseñado.
En este tipo de sistemas, los vínculos entre módulos son mínimos: cambiar uno por otro no representa una dificultad real. Incluso puede que algunos módulos ni siquiera se conozcan directamente, pero aun así colaboran para lograr un objetivo común.

Además, cada módulo tiene una responsabilidad clara y coherente.
Sabe lo que debe hacer y nada más, y todos sus elementos están alineados semánticamente con ese propósito.

El resultado es un sistema flexible, comprensible y fácil de mantener, donde cada parte puede evolucionar sin romper el todo.

A modo de cierre

Diseñar y modelar son dos caras de la misma moneda.

Modelamos para representar bien la realidad. Diseñamos para que esa representación funcione en el tiempo.

Un buen modelo sin un buen diseño se desmorona al crecer.

Un buen diseño sin un buen modelo pierde el rumbo y no resuelve el problema correcto.

En el día a día, muchas veces no los distinguimos claramente, y está bien: en la práctica se entrelazan. Pero entender sus diferencias nos ayuda a tomar mejores decisiones, escribir mejor código y construir sistemas más sólidos.

El desafío no está solo en que el software funcione, sino en que pueda seguir funcionando bien a medida que cambia.

Y ahí es donde el diseño y el modelado cumplen su rol más importante.

Gracias por llegar hasta el final.

Si te sirvió o te dejó pensando, me encantaría saber tu opinión en los comentarios.

Y si creés que puede ayudarle a alguien más, no dudes en compartirlo.

🤔 ¿Por qué debes aprender diseño de software en el frontend?

Nicolás Azuaga — Mon, 04 Aug 2025 12:49:28 +0000

Un poco de contexto

En un contexto en el que la inteligencia artificial gana cada vez más terreno, si queremos destacarnos como desarrolladores —y que la IA sea un potenciador de nuestras habilidades y no “algo que nos va a quitar el trabajo”— es fundamental que dominemos las bases y fundamentos del diseño de software.

En paralelo, vivimos una época de gran accesibilidad al desarrollo frontend, lo cual es algo positivo. Cada vez más personas ingresan al mundo del código gracias a bootcamps, cursos acelerados y plataformas accesibles.

Pero esa misma accesibilidad también tiene un efecto colateral: muchas veces se aprende primero a usar un framework sin comprender las bases que sostienen un software bien diseñado. Y eso genera código que funciona... pero es difícil de mantener, escalar o probar.

No es una crítica a quienes están empezando —todos arrancamos sin saber mucho, y eso está bien—, sino una invitación a ir más allá del “cómo se hace” y empezar a entender el “por qué se hace así”, y desarrollar criterio propio a la hora de programar.

Como dice el dicho: “Si todo lo que tenés es un martillo, todo te parece un clavo.”

Y eso es justamente lo que pasa cuando lo único que conocemos son herramientas, como useEffect, Context o Redux: intentamos resolver todo desde la UI, aunque no siempre sea el mejor lugar.

Aunque el frontend se ubica en los extremos del sistema, es el punto de contacto crítico con el usuario. Una interacción fallida —como un botón que no responde— puede hacer irrelevante toda la lógica del backend. Esto no solo afecta la experiencia, sino que compromete la percepción de calidad del producto, generando pérdida de tiempo, dinero y confianza.

Por eso es tan importante escribir código que no solo funcione, sino que pueda crecer, adaptarse y sostenerse a largo plazo. Conocer los principios que hacen que un software sea mantenible no es opcional: es parte del oficio.

Mi recorrido personal

Después de varios años desarrollando aplicaciones frontend con React y React Native, me di cuenta de algo: cada vez que tenía que mantener una base de código antigua —incluso una que había escrito yo mismo meses atrás— me preguntaba:

¿Por qué este código tiene que ser tan complicado? ¿Qué hice? ¿Qué significa "data"? ¿Será que esta carrera es para mí?

En mis comienzos como desarrollador frontend, me he encontrado con componentes con varias líneas de código, difíciles de entender y seguir. Cuando entregaba una nueva versión al equipo de QA con una nueva funcionalidad o fixes, siempre volvía a mí con nuevos bugs o “muertos vivos” que creía solucionados, pero que —por alguna extraña razón— reaparecían.

Cansado de esa situación, pensé que tenía que haber una forma mejor de hacer las cosas. Intuía que debía haber una manera de escribir código con menos fricción. Fue entonces cuando comencé a buscar y descubrí un mundo de libros y conceptos como Patrones de Diseño, principios SOLID, Arquitectura Limpia y Tests Unitarios (¿y esto último con qué se come?).

Entré al mundo de la informática sin una formación académica tradicional —sin carrera universitaria, más bien gracias a cursos, bootcamps y mucha perseverancia— y sentía que me faltaban ciertas bases. Pensaba que esas cosas “se enseñaban en la universidad”, y que por no haber pasado por ahí, me estaba perdiendo algo fundamental.

Con el tiempo entendí que no era tan así. Muchos de esos contenidos no están tan presentes en el ámbito académico, sino que hay que buscarlos por cuenta propia.

Leí libros como Clean Architecture de Robert C. Martin, y me sumergí en Domain-Driven Design de Eric Evans. Aunque me abrieron la cabeza, también me dejaron con muchas preguntas:

¿Cómo aplico estos principios en una app frontend?
¿Qué sentido tiene hablar de entidades o casos de uso dentro de un componente de React?
¿Dónde termina el dominio y empieza la UI?
¿A qué llaman dominio?
¿Qué significa diseño de software?
¿Qué es un modelo y para qué sirve el modelado?

Hace casi dos años decidí estudiar una tecnicatura en programación para cerrar esa etapa personal y sacarme el síndrome del impostor. La universidad me enseñó muchas cosas y me abrió aún más la mente, pero incluso al borde de graduarme, veo que estos temas específicos que quiero compartir con ustedes siguen sin divulgarse lo suficiente.

Por eso, esta serie es mi intento de acercarles, a mi manera y con lo que fui aprendiendo durante estos años, esos conceptos que considero clave para escribir mejor código en el frontend. No pretendo mostrar “la forma correcta”, sino divulgar ideas que puedan ser aplicadas según el contexto, y no por dogma.

🚩 ¿Te pasó esto?

El código funciona, pero nadie quiere tocarlo.
Un feature nuevo termina rompiendo otros sin que te des cuenta.
Tenés lógica duplicada en distintos lugares de la app.
No sabés dónde poner cierta lógica, así que termina en helpers.js o utils.ts.
Funciones con muchos ifs o switches que se vuelven difíciles de seguir.
Querés aplicar pruebas unitarias, pero el código está tan acoplado que parece imposible.
No sabés cómo diseñar una app ni por dónde empezar.

A mí también. Por eso, en esta serie de artículos que iré publicando, mi objetivo es acercarte conceptos que fui aprendiendo a lo largo de mi camino como desarrollador. Tal vez te sirvan y sumes herramientas a tu repertorio.

✅ Conclusión

👉 ¿Por qué deberías aprender diseño de software en el frontend?
Porque dominar el diseño de software te convierte en un mejor desarrollador. Te permite tomar decisiones más sólidas, escribir código que escala, colaborar mejor con tu equipo y aprovechar la IA como una verdadera extensión de tu capacidad técnica. No se trata solo de escribir código que funciona, sino de construir soluciones que perduran.

🙌 Gracias por estar acá

Si te interesa el tema, o te sentís identificado con lo que conté, te invito a seguir la serie.

✨ Prólogo — Cómo está construida esta serie de diseño de software en el frontend

Nicolás Azuaga — Mon, 04 Aug 2025 12:28:49 +0000

Esta serie es mi intento de acercarte conceptos clave de diseño y arquitectura de software aplicados al frontend, especialmente en contextos móviles con React Native. Está pensada desde la práctica, con ejemplos concretos y una app didáctica para seguir paso a paso.

📦 Tecnologías utilizadas

La serie está basada en el siguiente stack:

React Native CLI (no Expo)
TypeScript
React Navigation
React Native Testing Library
Redux para manejo de estado
Librerías auxiliares según se necesiten

Aclaración

Si bien los ejemplos estarán orientados al frontend móvil, los conceptos pueden ser trasladados a otros tipos de aplicación, ya sea web o backend.

⚛️ ¿Por qué con React Native CLI y TypeScript?

Elegí React Native CLI porque es la herramienta con la que más experiencia tengo y me siento más cómodo. Además, usaré TypeScript para aprovechar sus ventajas en tipado estático, lo que ayuda a escribir código más seguro y mantenible.

Noto que hay poco material en español sobre temas profundos de React Native combinados con TypeScript, y este es mi pequeño aporte.

🧢 La app que vamos a construir

Para mantener la serie divertida y cercana, vamos a desarrollar una app inspirada en el mundo Pokémon, pensada desde el enfoque de un entrenador.

App de Entrenador Pokémon

La app incluye:

Lógica de captura de Pokémon

Gestión del equipo (máximo de 6 Pokémon activos)

Guardería para Pokémon extra

Mochila con ítems (por ejemplo, Pokébolas)

Tipos de Pokébolas y su uso en capturas

Esta app no es una Pokédex, sino una representación simplificada de la experiencia de un entrenador, lo que nos permite modelar entidades, casos de uso, dependencias y flujos reales sin caer en ejemplos artificiales.

🧪 Cómo seguir los ejemplos

Voy a mantener un repositorio abierto con el código de la app:

🔗 Repositorio en GitHub (próximamente)

Cada capítulo de la serie incluirá ejemplos comentados y enlaces al código correspondiente. No necesitás conocimientos previos avanzados, pero se recomienda experiencia básica con React Native y TypeScript.

🎯 Enfoque de la serie

La serie está enfocada en cómo implementar principios de diseño en el frontend y divulgar estas ideas para tenerlas como guía y referencia. No se trata de aplicarlas como un dogma ni como la única verdad, sino de comprender que estos conceptos existen y pueden aplicarse según el contexto.

Habrá veces en que la implementación se sentirá forzada o exagerada para el tamaño de la app, pero eso también es parte del ejercicio: nos sirve para ejemplificar y analizar los pros y contras de dichas implementaciones.

En particular, vamos a ver:

Cómo aplicar principios SOLID en React Native
Cómo estructurar una app usando Clean Architecture
Qué significa Domain-Driven Design (DDD) en el frontend
Patrones comunes y errores frecuentes en diseño
Cómo testear apps desde el dominio hacia la UI

📚 Índice general de la serie

📌 Serie: Diseño de Software en el Frontend — Índice

Gracias por sumarte a esta serie 🙌

Te invito a seguirla, compartirla, y usarla como una guia o referencia para mejorar tu código y tus decisiones como desarrollador o desarrolladora.

📚 Serie: Diseño de Software en el Frontend — Índice

Nicolás Azuaga — Tue, 29 Jul 2025 05:14:49 +0000

Bienvenidos al índice de la serie donde ire publicando artículos sobre diseño de software y arquitectura aplicado al frontend, con ejemplos prácticos en React Native y TypeScript.

Lista de artículos publicados

Próximos artículos (en preparación) 🚧

🧠 Paradigmas de programación aplicados al diseño
🛠️ Principios de diseño vs patrones de diseño
☢️ Code Smells en el frontend
🧱 Principios SOLID con ejemplos prácticos en React Native
📦 Introducción a Domain-Driven Design (DDD)
🏗️ Arquitectura Limpia en React Native
🔷 Arquitectura Hexagonal en React Native
🛑 Manejo de Errores como un Pro
✔️ Introducción a Test Driven Design (TDD)
📊 Diagramas UML: ¿Valen la pena?
🧪 Tests más robustos con el patrón Test API en React Native

Nota: Cada vez que publique un nuevo artículo, actualizaré este índice para facilitar la navegación por la serie, los títulos pueden llegar a cambiar ya que están en preparación.

¡Gracias por seguir la serie!