Skip to main content

High-level structure

Booker4j is organised into two main areas: form handling and chat.

Form area​

  • Configuration and loading — Reads and validates form definitions (e.g. from YAML). Supports hot-reload so config changes can be picked up without a full restart.
  • Engine — Drives form navigation: which question is current, what comes next, branching, and when the form is complete. Uses a stack-based traversal so “go back” and branching behave correctly.
  • Validation — Runs validation rules on answers (required, format, business rules) before accepting them. Uses a strategy-style setup so new validators can be added without changing core flow.
  • Session — Stores form state (e.g. in Redis and optionally MongoDB) so progress is preserved across requests and can be resumed or archived.

Chat area​

  • API — Exposes endpoints that accept a user message and return the assistant reply, current question, and form state (and optionally stream the reply).
  • Orchestration — One component coordinates the flow: receive message, classify intent, call the right handler (answer, knowledge, clarification, navigation, etc.), and return the response.
  • Intent classification — Uses an LLM (or similar) to classify the user’s intent from the latest message and conversation context.
  • Handlers — Separate handlers for answering the current question, answering knowledge questions, clarifications, corrections, navigation (back, skip), language change, greetings, confirmation, and out-of-scope messages.
  • Knowledge — One or more knowledge bases (e.g. vector and file-based) that can be queried to generate answers about services, pricing, or policies.
  • Session — Chat session is linked to the form session so that conversation and form progress stay in sync.

The form area is agnostic of natural language; the chat area adds the conversational layer and calls into the form engine to submit answers and move through the flow.