docs: [TESIS-50] add technical documentation, ADRs and CLAUDE.md#15
docs: [TESIS-50] add technical documentation, ADRs and CLAUDE.md#15TomasMartin2004 wants to merge 2 commits into
Conversation
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
| ### Sidekiq | ||
|
|
||
| - ✅ El estándar de facto para background jobs en Rails — comunidad enorme | ||
| - ✅ Dashboard web (Sidekiq Web UI) | ||
| - ✅ Alto throughput con workers concurrentes (threads) | ||
| - ❌ **Requiere Redis** — dependencia adicional en desarrollo y producción | ||
| - ❌ Complejidad de operaciones adicional (Redis replication, persistence) | ||
| - ❌ En Rails 8 con Solid Queue, Redis no es necesario |
There was a problem hiding this comment.
Muy bueno!
Yo hubiera ido a Sidekiq directamente por costumbre o comunidad, pero te tomo el punto de que no depender de Redis es un plus bastante bueno. Vamos a ver como sale (confio)
| ### 5.3 Reglas para tablas | ||
|
|
||
| Toda tabla de dominio debe incluir: | ||
|
|
||
| ```ruby | ||
| t.references :company, null: false, foreign_key: true | ||
| ``` | ||
|
|
||
| Las tablas de configuración del sistema (sin datos de tenant) como `services` (plantillas de APIs) no llevan `company_id`. |
There was a problem hiding this comment.
Solución robusta, lógica, peero....
Si una clase depende de User por ejemplo, o algo que ya dependa del tenant, dejamos explicito el tenant también?
Opción 1: Tenant explicito en cada tabla
👍 Mas trazable, menos riesgo de filtrar datos cross-tenant, mas velocidad de queries, ya que no requiere un Join para inferir el tenant
Opción 2: Inferir el Tenant cuando sea posible
Datos mas atómicos, responsabilidad unica, pero puede entorpecer queries.
Seguimos con este enfoque? no lo veo mal, solo lo planteo para tenerlo en cuenta, de todas formas, ningun tenant_id deberia cambiar con el tiempo
| @@ -0,0 +1,143 @@ | |||
| # Estructura de Features (Dominios de Negocio) | |||
There was a problem hiding this comment.
Acá ojo de nuevo, porque me da la impresión de que esto se está tomando así para seguir la misma convención que definimos en el front, pero al tratarse de Rails, que tiene una filosofía "Convention over Configuration", Puede terminar en codigo mas verborragico, que es justamente lo que rails evita por defecto.
Chequeemos si no conviene una arquitectura hexagonal, por poner un ejemplo.
…ntegrations, testing guide - Add section 6 to feature-structure.md: when to use PORO vs direct model call - Update ADR-004: hexagonal architecture adopted for integrations domain only - Add docs/guidelines/testing.md: full testing guide with spec templates - Update guidelines README with testing.md entry Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2 participants
Ticket de Jira
https://proyectofinalfrlp.atlassian.net/browse/TESIS-50
Descripción
Agrega la documentación técnica base del repositorio backend. El objetivo es que Claude Code pueda leer una card de Jira y generar código bajo los estándares del proyecto sin necesidad de contexto adicional.
Incluye el
CLAUDE.md(cargado automáticamente por Claude al inicio de cada sesión), 7 ADRs con las decisiones arquitectónicas tomadas y 5 guidelines con patrones de implementación concretos.Cambios realizados
CLAUDE.mdcon stack, arquitectura, patrones de implementación, multi-tenancy, comandos y sección "Antes de empezar cualquier tarea" con lectura obligatoria de documentosdocs/adr/ADR-001aADR-007documentando las decisiones: stack Rails, Devise+JWT, row-level multi-tenancy, arquitectura Controller-PORO-Serializer-Policy, Blueprinter, Solid Queue y Punditdocs/guidelines/architecture.mdcon estructura de carpetas, flujo de request, dominios de negocio y patrones de implementacióndocs/guidelines/code-conventions.mdcon RuboCop, Ruby conventions, naming y patrones de testingdocs/guidelines/feature-structure.mdcon los 6 dominios del OMS y reglas de dependenciadocs/guidelines/git-workflow.mdcon ramas, commits, Lefthook y CIdocs/guidelines/pr-guidelines.mdcon guía de redacción de PRs y ejemplosEvidencia visual
N/A
Cómo probar
CLAUDE.mdautomáticamente al inicioImpacto y consideraciones
¿Introduce breaking changes?
No
¿Requiere nuevas variables de entorno?
No
¿Afecta la arquitectura o genera un nuevo patrón?
No — documenta decisiones ya tomadas e implementadas en el setup inicial del proyecto