Herramientas de diseño necesarias cuando un desarrollador junior piensa más allá del CRUD

Una vez completadas las funciones CRUD, llega el momento en que el mantenimiento empieza a dar miedo. El hábito de empezar por el diseño de tablas complica el sistema. Este artículo contiene metodologías concretas para separar el código por unidades de dominio y estandarizar el entorno, con el fin de limitar el alcance de las modificaciones.

Aumentar la cohesión del código: Separación de la lógica y el acceso a datos

Si la lógica de negocio se mezcla en el controlador, tendrás que rehacer todo el código cada vez que cambies la estructura de la base de datos. Implementa una arquitectura por capas para aislarlos. Puedes reducir el tiempo de mantenimiento de la base de código en aproximadamente un 40%.

Los pasos para separar el acceso a datos y la lógica son los siguientes:

Mueve el código de validación del controlador al DTO de solicitud y utiliza anotaciones de validación.
Reúne la lógica dispersa en scripts de transacciones dentro de métodos internos de la entidad de dominio.
En lugar de usar controladores de DB específicos, declara una interfaz que defina comportamientos de persistencia para separarlos de la capa de dominio.

Incluso si cambia el esquema de una tabla específica, las reglas principales permanecen intactas.

Crear entornos de prueba mediante inyección de dependencias

Si creas objetos directamente dentro de una clase con el operador new, las pruebas unitarias son imposibles. Implementa la inversión de control (IoC) para realizar pruebas independientes con objetos simulados (Mock) sin necesidad de servidores externos.

Este es un procedimiento práctico para aumentar la eficiencia de las pruebas:

Declara los colaboradores que utilizará el objeto como interfaces, no como clases concretas.
Configura el contenedor externo para inyectar la implementación adecuada en tiempo de ejecución.
Utiliza herramientas como @automock/jest para automatizar la configuración de dobles de prueba (test doubles).

Al utilizar esta estructura, puedes mejorar la velocidad de ejecución de las pruebas en más de un 20%.

Aislamiento de entidades y DTO

Si mapeas la estructura de la interfaz de usuario y las tablas de la base de datos uno a uno, tendrás que modificar el esquema de la DB incluso para arreglar una sola pantalla. Separa estrictamente los DTO para mensajes de red y las entidades de dominio.

Esta es la forma de aislarlos usando mapeadores:

Crea una clase mapeadora pura dedicada exclusivamente a la transformación de datos.
Mueve los datos solo dentro del mapeador para que no haya dependencias directas entre el DTO y la entidad.
Obliga a la capa de servicio a utilizar únicamente entidades.

No es necesario modificar la lógica aunque se cambie el almacén de datos.

Sincronizar el entorno de desarrollo con Docker Compose

Si el entorno local es diferente para cada desarrollador, la colaboración se detiene. Sincroniza el entorno escribiendo la infraestructura como código con Docker Compose.

Procedimiento para crear un entorno estándar:

Escribe la versión y las variables de entorno de la base de datos y el servidor de caché en el archivo docker-compose.yml.
Coloca el SQL del esquema inicial en la ruta /docker-entrypoint-initdb.d mediante volúmenes montados.
Evita problemas de dependencias utilizando un enlazador de paquetes como pnpm Workspaces.

Al terminar esta configuración, podrás levantar la infraestructura estándar en 3 segundos sin preocuparte por la configuración de la máquina local.

Modelar el dominio antes de diseñar las tablas

Si dibujas primero el diagrama entidad-relación (ERD), solo obtendrás lógica fragmentada centrada en los datos. Shopify hizo que más de 800 ingenieros dejaran atrás el legado centrado en esquemas físicos para cambiar a un modelado centrado en objetos de negocio.

Estos son los pasos para empezar el modelado de dominio:

Enumera los sustantivos y verbos principales del dominio basándote en los casos de uso y el lenguaje ubicuo.
Define las entidades que requieren transiciones de estado y los objetos de valor (Value Objects) que tienen atributos inmutables.
Determina las raíces de agregado (Aggregate Roots) para verificar la integridad del negocio por unidad de transacción.

Este enfoque confina el alcance de la modificación dentro de módulos específicos incluso cuando cambian los requisitos. El diseño de sistemas complejos es la alternativa más práctica para eliminar la sensación de estar perdido.

Herramientas de diseño necesarias cuando un desarrollador junior piensa más allá del CRUD

Aumentar la cohesión del código: Separación de la lógica y el acceso a datos

Los pasos para separar el acceso a datos y la lógica son los siguientes:

Mueve el código de validación del controlador al DTO de solicitud y utiliza anotaciones de validación.
Reúne la lógica dispersa en scripts de transacciones dentro de métodos internos de la entidad de dominio.
En lugar de usar controladores de DB específicos, declara una interfaz que defina comportamientos de persistencia para separarlos de la capa de dominio.

Incluso si cambia el esquema de una tabla específica, las reglas principales permanecen intactas.

Crear entornos de prueba mediante inyección de dependencias

Este es un procedimiento práctico para aumentar la eficiencia de las pruebas:

Declara los colaboradores que utilizará el objeto como interfaces, no como clases concretas.
Configura el contenedor externo para inyectar la implementación adecuada en tiempo de ejecución.
Utiliza herramientas como @automock/jest para automatizar la configuración de dobles de prueba (test doubles).

Al utilizar esta estructura, puedes mejorar la velocidad de ejecución de las pruebas en más de un 20%.

Aislamiento de entidades y DTO

Esta es la forma de aislarlos usando mapeadores:

Crea una clase mapeadora pura dedicada exclusivamente a la transformación de datos.
Mueve los datos solo dentro del mapeador para que no haya dependencias directas entre el DTO y la entidad.
Obliga a la capa de servicio a utilizar únicamente entidades.

No es necesario modificar la lógica aunque se cambie el almacén de datos.

Sincronizar el entorno de desarrollo con Docker Compose

Si el entorno local es diferente para cada desarrollador, la colaboración se detiene. Sincroniza el entorno escribiendo la infraestructura como código con Docker Compose.

Procedimiento para crear un entorno estándar:

Escribe la versión y las variables de entorno de la base de datos y el servidor de caché en el archivo docker-compose.yml.
Coloca el SQL del esquema inicial en la ruta /docker-entrypoint-initdb.d mediante volúmenes montados.
Evita problemas de dependencias utilizando un enlazador de paquetes como pnpm Workspaces.

Al terminar esta configuración, podrás levantar la infraestructura estándar en 3 segundos sin preocuparte por la configuración de la máquina local.

Modelar el dominio antes de diseñar las tablas

Estos son los pasos para empezar el modelado de dominio:

Enumera los sustantivos y verbos principales del dominio basándote en los casos de uso y el lenguaje ubicuo.
Define las entidades que requieren transiciones de estado y los objetos de valor (Value Objects) que tienen atributos inmutables.
Determina las raíces de agregado (Aggregate Roots) para verificar la integridad del negocio por unidad de transacción.

Herramientas de diseño necesarias cuando un desarrollador junior piensa más allá del CRUD

관련 영상

Por favor, DEJA de crear proyectos CRUD (Un error común de los desarrolladores)

Herramientas de diseño necesarias cuando un desarrollador junior piensa más allá del CRUD

Aumentar la cohesión del código: Separación de la lógica y el acceso a datos

Crear entornos de prueba mediante inyección de dependencias

Aislamiento de entidades y DTO

Sincronizar el entorno de desarrollo con Docker Compose

Modelar el dominio antes de diseñar las tablas

커뮤니티의 다른 글

사내 시스템에 llm api 붙일 때 마주하는 현실적인 한계와 대응법

레거시 백엔드에 GPT-6 Astra 붙일 때 예산 승인과 보안 통과를 먼저 끝내는 법이 있습니다

에이전트끼리 대화하다 6천만 원 청구서가 나오는 이유

사내 RAG 벡터 검색에 Okta 권한 필터를 직접 거는 방법

브라우저 에이전트에게 내 구글 계정을 통째로 넘기면 안 되는 이유

Apple Won the AI Race

댓글 (0)

Herramientas de diseño necesarias cuando un desarrollador junior piensa más allá del CRUD

Aumentar la cohesión del código: Separación de la lógica y el acceso a datos

Crear entornos de prueba mediante inyección de dependencias

Aislamiento de entidades y DTO

Sincronizar el entorno de desarrollo con Docker Compose

Modelar el dominio antes de diseñar las tablas