Documentación del sistema: narrativa de flujo de negocio y de interacción (parte 4)

 Estoy de acuerdo con todo lo que dijiste. Quiero seguir avanzando.

Perfecto. Creo que llegamos a un punto donde conviene dejar de pensar en tablas aisladas y empezar a pensar en el modelo de dominio completo de Dentalia.

Mi propuesta es que construyamos el sistema "desde el centro hacia afuera". Es decir, primero definimos las entidades fundamentales y luego los módulos que las utilizan.

Mapa del dominio

Hoy yo dibujaría el corazón del sistema así:

                                Paciente
                                    │
                                    │ 1
                                    │
                                    ▼
                              Odontograma
                                    │
                                    │
                           (diagnóstico clínico)
                                    │
                                    ▼
                               Prestación
                                    ▲
                                    │
                                    │
                     TratamientoPropuestaItem
                                    │
                                    │ N
                                    ▼
                         TratamientoPropuesta
                                    │
                                    ▼
                                 Cobro
                                    │
                                    ▼
                               Facturación

Observá algo interesante: Prestación no está "debajo" del odontograma. Está al costado. Es un catálogo del sistema, utilizado por varios módulos.

---

Módulo 1: Prestaciones

Creo que éste debe ser el próximo módulo que diseñemos.

Su responsabilidad será responder preguntas como:

• ¿Cómo se llama este tratamiento?

• ¿Cuál es su código?

• ¿Cuál es su precio sugerido?

• ¿Pertenece a qué categoría?

• ¿Está vigente?

• ¿Requiere seleccionar una pieza?

• ¿Requiere seleccionar una superficie?

• ¿Se puede presupuestar?

• ¿Se puede facturar?

Fijate que no depende de ningún paciente.

Es un verdadero catálogo.

---

Mi propuesta para la entidad Prestacion

Todavía no escribo la migración; primero quiero consensuar el modelo.

Identidad

id
codigo
nombre

---

Organización

categoria_id
orden
activo

---

Configuración clínica

requiere_pieza
requiere_superficie

---

Configuración administrativa

precio_base

facturable

presupuestable

---

Auditoría

created_at

updated_at

---

Y aparece un nuevo actor

Mientras escribía esto apareció naturalmente otra entidad.

No quiero crearla todavía, pero sí nombrarla.

CategoriasPrestacion

Porque tarde o temprano vamos a querer:

Operatoria

Endodoncia

Cirugía

Prótesis

Ortodoncia

Implantología

Preventiva

Radiología

Y no quisiera que fueran strings repetidos en la tabla de prestaciones.

---

El odontograma se vuelve muchísimo más simple

En vez de pensar

{
    "codigo": "obturacion-pendiente"
}

yo ya lo interpreto mentalmente como

Prestacion::codigo

O sea, el JSON ya no "describe" un tratamiento.

Lo referencia.

Eso me gusta muchísimo desde el punto de vista del diseño.

---

La primera pantalla administrativa

Cuando exista este catálogo, podremos construir una pantalla completamente independiente del resto del sistema:

Administración → Prestaciones

Con una grilla de shadcn/ui que permita:

• buscar por código;

• buscar por nombre;

• filtrar por categoría;

• filtrar por activas/inactivas;

• editar;

• desactivar;

• crear nuevas prestaciones.

Esa pantalla será utilizada por el administrador del consultorio y alimentará automáticamente el odontograma, las propuestas, los cobros y la facturación.

---

El siguiente documento que propondría elaborar

Hasta ahora hemos documentado el módulo de Propuestas de Tratamiento. El siguiente documento que redactaría sería la Especificación Técnica del Catálogo de Prestaciones.

Ese documento definiría con el mismo nivel de detalle:

1. La responsabilidad del catálogo.

2. Las reglas de negocio.

3. El modelo de datos.

4. Las relaciones Eloquent.

5. La API REST.

6. Las pantallas Inertia + React.

7. Las restricciones e invariantes (por ejemplo, que codigo sea único e inmutable una vez utilizado).

8. Cómo interactúa con el odontograma y con las propuestas.

Mi sugerencia es que no escribamos aún ninguna migración. Si mantenemos esta forma de trabajo, primero tendremos una especificación completa del módulo de Prestaciones y luego las migraciones, modelos, controladores y pantallas saldrán de manera casi mecánica y, sobre todo, coherente entre sí.