Glossary

This document provides definitions for key terms and concepts used throughout the IT Ticketing Service application. It is intended to serve as a shared vocabulary for the development team, covering application-specific domain language, technical jargon, and architectural components.

---

Application Terms

These terms define the core domain concepts of the IT ticketing system.

• Ticket: The central domain object of the application, representing a single support request or issue. Each ticket has a distinct lifecycle and is the primary entity managed by the service's CRUD operations. A ticket is characterized by several attributes, including its title, description, status, priority, requester, and assignee. For a detailed breakdown of the data model, see the Ticket Data Model documentation.

• Requester: The end-user who initiated a support ticket. In this system, the requester is identified by their email address (requesterEmail). The API allows for filtering tickets based on the requester's email.

  # Example: Get all tickets submitted by user@example.com
  GET /api/tickets?requesterEmail=user@example.com

• Assignee: The support agent or team member assigned to investigate and resolve a ticket. This is tracked via the assignedTo field, which also uses an email address for identification.

• Status: The current state of a ticket within its lifecycle. The status field is critical for tracking progress and workflow management. The application defines a specific set of allowed status values:

  • OPEN: The ticket has been created but not yet assigned or worked on.
  • IN_PROGRESS: An assignee is actively working on the ticket.
  • WAITING_ON_CUSTOMER: The assignee is waiting for a response or action from the requester.
  • RESOLVED: The issue has been fixed, but the ticket is not yet formally closed.
  • CLOSED: The ticket is considered complete and closed.

• Priority: A classification of a ticket's urgency, which helps support teams prioritize their work. The defined priority levels are:

  • LOW
  • MEDIUM
  • HIGH
  • CRITICAL

Technical Terms

These are general software engineering terms as they apply specifically to this project's implementation.

• DTO (Data Transfer Object): A design pattern used to transfer data between application layers, particularly between the service layer and the API (controller) layer. In this application, DTOs are used as the request and response bodies for the REST API. This decouples the API's public contract from the internal database structure (JPA Entities), allowing the data model to evolve independently of the API.

• JPA (Java Persistence API): The standard Java specification for Object-Relational Mapping (ORM). The application uses Spring Data JPA to implement its persistence layer. This framework significantly simplifies data access code by providing repository interfaces that automatically generate queries based on method names.

• ORM (Object-Relational Mapping): The technique of mapping application domain objects (Java classes) to records in a relational database (MySQL tables). Spring Data JPA, built on top of a JPA provider like Hibernate, handles the ORM, translating object-oriented operations into SQL queries.

• AMQP (Advanced Message Queuing Protocol): The open standard protocol used for asynchronous, message-oriented middleware. The application leverages the spring-boot-starter-amqp dependency to integrate with a RabbitMQ message broker, enabling event-driven communication.

• REST (Representational State Transfer): The architectural style governing the design of the application's web-based API. The API adheres to REST principles by using standard HTTP methods (GET, POST, PUT, DELETE), resource-based URLs (e.g., /api/tickets/{id}), and stateless communication.

Architecture Terms

These terms describe the components of the application's internal software architecture. For a complete overview, refer to the Core Architecture documentation.

• Controller: A Spring MVC component responsible for handling incoming HTTP requests, processing headers and request bodies, and returning an HTTP response. Controllers act as the entry point to the API, delegating business logic execution to the Service layer. They are responsible for mapping DTOs from JSON and vice-versa.

• Service: The layer that contains the application's core business logic. Service components are responsible for orchestrating operations, such as validating data, calling repository methods to persist data, and publishing events to the message broker. This layer keeps business rules separate from both web concerns (Controllers) and data access concerns (Repositories).

• Repository: A data access layer component implemented using Spring Data JPA interfaces. Repositories provide a high-level, object-oriented abstraction for performing CRUD (Create, Read, Update, Delete) operations on domain entities without requiring developers to write boilerplate JDBC or SQL code.

• Entity: A Plain Old Java Object (POJO) that is annotated with JPA annotations (e.g., @Entity, @Table, @Id) to map it directly to a table in the MySQL database. An Entity represents the persistent state of a domain object, such as the Ticket entity. It is distinct from a DTO, as it represents the internal data structure, not the public API contract. See the Ticket Data Model documentation for more details.

• Event: An asynchronous message representing a significant occurrence within the application, such as the creation or update of a ticket. These events are published to a message broker (RabbitMQ) to enable decoupled, asynchronous processing by other services. This is a cornerstone of the application's Event-Driven Architecture.

  • Event Type: CREATED (on new ticket creation)
  • Event Type: UPDATED (on existing ticket modification)

Infrastructure Terms

These terms relate to the external systems and configurations the application depends on.

• Exchange: A core component in RabbitMQ that acts as a message router. Producers publish messages to an exchange, which then routes them to one or more bound queues based on routing keys and exchange type. This application publishes all ticket-related events to a single, dedicated exchange.

  # The named exchange for ticket events
  # (from README.md)
  ticket.exchange

  Gotcha: Publishing directly to a queue is possible but not best practice. Using an exchange decouples the publisher from the queue, allowing for more flexible routing scenarios (e.g., fanning out a single event to multiple consumer queues).

• Queue: A data structure within RabbitMQ that stores messages until they are consumed by a listening application. Queues are bound to exchanges to receive messages. While the producer in this application does not need to know the queue name, consumer services will subscribe to specific queues to process ticket events.

• Routing Key: An "address" attribute of a message that the exchange uses to decide how to route it. This application uses a static routing key for all ticket events.

  # The routing key used for all published ticket events
  # (from README.md)
  ticket.routing.key

  This setup implies a topic or direct exchange where a consumer's queue is bound with a matching key.

• Actuator: A Spring Boot sub-project that adds production-ready operational features to the application. It exposes a set of HTTP endpoints for monitoring application health, metrics, configuration, and more. The /actuator/health endpoint is particularly important for automated health checks in container orchestration platforms (like Kubernetes) and load balancers.

  # Check the application's health status
  GET /actuator/health

  The Actuator provides critical observability, which is essential for managing the application both in its current on-premises environment and after migration to Google Cloud.