leandro/phronCare
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects 1 Releases Wiki Activity

feat(sales): incorporar DTO de lectura para Delivery Note #23

New Issue
Closed
opened 2026-03-19 18:08:04 +00:00 by leandro · 0 comments
leandro commented 2026-03-19 18:08:04 +00:00
Owner
Copy Link

Objetivo

Desacoplar el contrato de la API de la entidad de dominio (EDeliveryNote), introduciendo un DTO específico de lectura (DeliveryNoteDto) alineado con el patrón utilizado en Quotes y Expeditions.

Contexto funcional

Actualmente el módulo de Delivery Note ya cuenta con:

  • Repositorio:

    • IPhSDeliveryNoteRepository
    • PhSDeliveryNoteRepository

  • Core:

    • IDeliveryNoteDom
    • DeliveryNoteService

  • API:

    • DeliveryNoteController
    • Endpoints:
      • GET by id
      • GET by deliveryNoteNumber
      • GET by quoteId

El problema actual es que la API expone directamente la entidad de dominio EDeliveryNote, lo que genera:

  • Acoplamiento entre API y Domain
  • Falta de control del contrato de salida
  • Inconsistencia con módulos como Quotes y Expeditions (que usan DTOs)

Alcance

  • Definir DeliveryNoteDto (cabecera + items)
  • Definir DeliveryNoteItemDto
  • Ubicar DTOs en Domain/Dtos/Sales
  • Implementar proyección a DTO en el repositorio
  • Extender IPhSDeliveryNoteRepository con métodos de lectura DTO
  • Ajustar DeliveryNoteService para consumir DTOs
  • Ajustar DeliveryNoteController para devolver DTOs
  • Mantener endpoints existentes sin cambios de ruta

Fuera de alcance

  • Modificaciones en modelos EF (Data)
  • Cambios en entidades de dominio (EDeliveryNote)
  • Cambios en base de datos
  • Cambios en UI (Blazor)
  • Nuevos endpoints
  • Lógica de negocio adicional
  • Integración con PDF o documentos

Criterios de aceptación

  • Existe DeliveryNoteDto y DeliveryNoteItemDto
  • Los DTOs están alineados con el patrón de QuoteDto y ExpeditionDto
  • El repositorio expone métodos que devuelven DTO
  • El service utiliza DTO en lugar de entidad para lectura
  • El controller devuelve DTO en todos sus endpoints
  • No se exponen entidades E* en la API
  • No se rompen endpoints existentes
  • El comportamiento HTTP (200 / 404) se mantiene intacto

Decisiones de diseño

  • Ubicación DTO: Domain/Dtos/Sales
  • Nivel de detalle: cabecera + items
  • Estrategia de mapping: proyección en repositorio (alineado con Quotes/Expeditions)
  • Estrategia de transición: reemplazo directo en capa de lectura
  • Naming DTO: PascalCase limpio (no replicar nombres crudos de DB)

Entregable esperado

  • Nuevos DTOs implementados:
    • DeliveryNoteDto
    • DeliveryNoteItemDto
  • Repository extendido con métodos DTO
  • Service actualizado a DTO
  • Controller devolviendo DTO
  • Código consistente con arquitectura del proyecto
  • Endpoints funcionando correctamente sin exponer entidades de dominio
## Objetivo Desacoplar el contrato de la API de la entidad de dominio (`EDeliveryNote`), introduciendo un DTO específico de lectura (`DeliveryNoteDto`) alineado con el patrón utilizado en Quotes y Expeditions. --- ## Contexto funcional Actualmente el módulo de Delivery Note ya cuenta con: - Repositorio: - IPhSDeliveryNoteRepository - PhSDeliveryNoteRepository - Core: - IDeliveryNoteDom - DeliveryNoteService - API: - DeliveryNoteController - Endpoints: - GET by id - GET by deliveryNoteNumber - GET by quoteId El problema actual es que la API expone directamente la entidad de dominio `EDeliveryNote`, lo que genera: - Acoplamiento entre API y Domain - Falta de control del contrato de salida - Inconsistencia con módulos como Quotes y Expeditions (que usan DTOs) --- ## Alcance - Definir `DeliveryNoteDto` (cabecera + items) - Definir `DeliveryNoteItemDto` - Ubicar DTOs en `Domain/Dtos/Sales` - Implementar proyección a DTO en el repositorio - Extender `IPhSDeliveryNoteRepository` con métodos de lectura DTO - Ajustar `DeliveryNoteService` para consumir DTOs - Ajustar `DeliveryNoteController` para devolver DTOs - Mantener endpoints existentes sin cambios de ruta --- ## Fuera de alcance - Modificaciones en modelos EF (Data) - Cambios en entidades de dominio (`EDeliveryNote`) - Cambios en base de datos - Cambios en UI (Blazor) - Nuevos endpoints - Lógica de negocio adicional - Integración con PDF o documentos --- ## Criterios de aceptación - Existe `DeliveryNoteDto` y `DeliveryNoteItemDto` - Los DTOs están alineados con el patrón de `QuoteDto` y `ExpeditionDto` - El repositorio expone métodos que devuelven DTO - El service utiliza DTO en lugar de entidad para lectura - El controller devuelve DTO en todos sus endpoints - No se exponen entidades `E*` en la API - No se rompen endpoints existentes - El comportamiento HTTP (200 / 404) se mantiene intacto --- ## Decisiones de diseño - Ubicación DTO: `Domain/Dtos/Sales` - Nivel de detalle: cabecera + items - Estrategia de mapping: proyección en repositorio (alineado con Quotes/Expeditions) - Estrategia de transición: reemplazo directo en capa de lectura - Naming DTO: PascalCase limpio (no replicar nombres crudos de DB) --- ## Entregable esperado - Nuevos DTOs implementados: - DeliveryNoteDto - DeliveryNoteItemDto - Repository extendido con métodos DTO - Service actualizado a DTO - Controller devolviendo DTO - Código consistente con arquitectura del proyecto - Endpoints funcionando correctamente sin exponer entidades de dominio
leandro added this to the Sales (Ventas, Facturación y Remitos) milestone 2026-03-19 18:08:04 +00:00
leandro added the
STORY
 label 2026-03-19 18:08:04 +00:00
leandro self-assigned this 2026-03-19 18:08:04 +00:00
leandro added this to the phronCare: Tablero DEV project 2026-03-19 18:08:04 +00:00
leandro changed title from feat(sales): incorporar DTO de lectura para Delivery Note #22 to feat(sales): incorporar DTO de lectura para Delivery Note 2026-03-19 18:08:14 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:42 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:45 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:47 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:49 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:51 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-23 03:07:52 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-24 20:24:05 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-24 20:24:07 +00:00
leandro moved this to Done in phronCare: Tablero DEV on 2026-03-25 13:27:46 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
STORY
bug
infra
refactor
tech-debt
No Label
STORY
Milestone
No items
No Milestone Sales (Ventas, Facturación y Remitos)
Projects
Clear projects
No project phronCare: Tablero DEV
Assignees
Clear assignees
No Assignees leandro
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: leandro/phronCare#23
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?