Domain Model: intelligentstaffingsystems
Domain Model: intelligentstaffingsystems
Diagram
Components
| Component | Purpose | Notes |
|---|---|---|
| Lead | Prospect/client record — exists before Keycloak account | keycloak_sub NULL until first login claims it via email match |
| ProjectRequest | Client project submission | business_name copied from Lead at creation time |
| Appointment | Booking with Lucas | Booked through the iOS app — proof of the pipeline |
| Message | Chat messages (one thread per lead) | sender_sub identifies who sent it; broadcasts_to :lead via Turbo Streams |
| CatalogEntry | Portfolio item under one of three pillars | Admin CRUD; public read. Pillar maps to the ISS value prop |
| CatalogImage | Image attachment for a catalog entry | Ordered by position |
Key Decisions
- Lead exists before auth — the registration form creates a Lead with keycloak_sub NULL; Keycloak account claims it on first login by email match. Admin sees every prospect, not just those who finished account creation.
- One message thread per lead — Message.lead_id IS the thread; no Conversation model. Simplest model for the client journey; revisit only if multi-project clients need separate threads.
- UUID primary keys everywhere — all models use UUIDs. Consequence: .last orders lexicographically, not by creation time.
- No Conversation/Thread model — intentionally excluded. Leads see their own thread, admin enters any thread.
- business_name denormalized onto ProjectRequest — copied from Lead at creation; avoids join for display.
Related
arch-dataflow-iss— runtime data flow (auth, messaging)arch-deployment-iss— where services runproject-iss— project page