Request a table
The public form validates event and seating choices before creating a UUID-tracked pending reservation.
FiredThe brief
Two rooms, one ticket.
A reservation platform serves two very different rooms. Guests want a seat with zero friction. Staff want control, filters, and a record of every call. The job was to let both work the same ticket without handing the wrong controls to the wrong person.
Stub 01 Front of house
The guest
Browse events and seatings, request a table, and get a confirmation code. No account, no friction.
Stub 02 Back of house
The staff
Sign in, filter the queue by event and status, assign a table, then approve or deny. Every call is logged.
Palette
Warm room, cool contrast.
Flavor da Casa had to feel like a warm, family-run dining room, not a cold booking tool. The palette is built from kitchen and dining-room materials: cinnamon wood and coffee bean for warmth, soft apricot for candlelight glow, and a deep blue-grey set against them for grounded, legible headings. The warm tones invite; the cool blue-grey keeps the interface calm and readable through a busy service.
Service choreography
A reservation moves like a ticket through service.
Every reservation runs the same line: a guest fires the request, the system stamps a confirmation, staff work the queue and assign a table, and a secured API plates the data for anyone downstream.
Send confirmation
EmailService sends the guest a formatted confirmation with event, seating time, and confirmation code.
SentFilter the queue
The dashboard narrows reservations by event and status so staff can work the next service window.
QueuedAssign a table
Authenticated users review full guest details and attach a valid dining table before approval.
PlatedExpose operations
The separate REST app uses bearer tokens and OpenAPI docs for third-party access.
Served 01
Guest surface
The reservation book
The guest flow keeps attention on event, seating, and contact details. It behaves like a host stand: collect the request, confirm the code, then move the ticket into the queue.
guest/reservation
02
Staff surface
The service queue
Staff do not need every record at once. They need the next decision. Event and status filters turn the reservation list into a working queue.
staff/reservations
03
Security surface
The locked staff door
The login screen marks the boundary between public browsing and operational authority. That boundary matters because approvals change the guest experience.
security/login
04
Integration surface
The documented API
Swagger turns the backend into something reviewable. The API is secured with JWT bearer tokens and separated from the Thymeleaf web app.
api/swagger
Architecture
One system, wired like infrastructure.
Clients hit the runnable apps, the apps call the domain modules, every module stands on the shared foundation, and persistence and mail sit at the edges. Dependencies flow down.
01 Clients
Staff browser
front of houseAPI client
third-party02 Delivery apps
app-web
Thymeleaf : 8080restaurant-api
REST : 8081auth-api
tokens : 808203 Domain modules
restaurant
events · reservationsauth
access04 Shared foundation
common
domain · application · web · infrastructure05 Persistence
MySQL
Spring Data JPABuilt for service
Proof the service holds.
01 Architecture
Multi-Module Clean Architecture
Maven multi-module project with shared common libraries. Each module (restaurant, auth, common) has its own Domain, Application, Infrastructure, and Presentation layers with strict dependency inversion.
Separate modules 02 Rules
Validation Framework
Custom ValidationService pattern per entity with Result/ValidatedResult wrapper types, field-level error binding to BindingResult, and dedicated validation services for Events, Seatings, Menus, MenuItems, DiningTables, and Reservations.
Field-level feedback 03 Dining room
Seating & Dining Table System
Seating CRUD with table assignments (many-to-many via SeatingTableEntity), capacity tracking, overlapping seating conflict detection, and cascade delete management.
Capacity logic 04 Service prep
Data Initialization Service
InitializeDataServiceImpl seeds the database with default dining tables, events, seatings, menus, and menu items on first startup, enabling immediate demo readiness.
Demo-ready seed data