Architecture - SOEN390-ConUNav/SOEN390-Mini-Cap-Project GitHub Wiki

4.1 Overview of Architecture

Architecture Style

Our backend follows a layered monolithic architectural style built with Spring Boot and operates within a RESTful client-server model. At the system level, it works as a REST API that communicates with a separate frontend application and connects to external services such as the Google Maps Directions and Places APIs. This macro-architecture was chosen because it gives a simple, predictable request-response flow that fits the needs of a navigation and mapping application, where each client request can be processed independently without maintaining server‑side session state.

The first layer of this layered architecture is the controller layer, which is responsible for exposing RESTful endpoints that can be accessed by the client application. This layer handles incoming HTTP requests, extracts and validates request parameters, and formats the responses sent back to the client in a consistent way. Controllers act as the entry point of the backend and focus only on request handling and producing the corresponding responses. They do not contain any business logic and instead pass on all processing to the service layer.

The second layer is the service layer, which contains the core application logic of the backend. This layer is responsible for processing data, applying application rules, and handling integrations with external APIs, such as the Google Maps Directions and Places APIs used to retrieve routes and points of interest for users. By centralizing this logic in services, the backend ensures that functionality is reusable across multiple controllers and avoids duplication when multiple endpoints depend on similar operations.

In addition, the backend includes Data Transfer Objects (DTOs) and enumerations to define clear and consistent data structures for communication between layers and with the client. DTOs are used to represent responses such as directions, route steps, and error messages, while enums define fixed sets of values such as transport modes, maneuver types, and place types. The backend also implements centralized exception handling through a global exception handler, allowing errors to be managed in a single location and making sure consistent error responses are displayed. Configuration classes are used to manage application-level concerns, such as CORS policies and external API configuration.

This layered monolithic architecture was chosen because it aligns well with the scope and complexity of our project. A monolithic structure keeps deployment simple and avoids the overhead of distributed systems, which would not provide significant benefits for a project of this size. The layered approach also fits naturally with Spring Boot’s conventions and makes it easy for team members to work in parallel on different parts of the system. We also considered more complex architectural styles such as hexagonal architecture or microservices, but these were intentionally not taken. Hexagonal architecture introduces additional abstraction layers that were unnecessary for our relatively small codebase, and microservices would have added operational complexity without improving performance or scalability for our use case. The layered monolithic approach therefore gave us the best balance of clarity, maintainability, and development speed.

Overall, this architectural style supports our domain effectively: navigation and mapping logic benefits from centralized business rules, consistent data structures, and a clean separation between request handling and external API integration. This makes the backend easier to extend as new features, endpoints, or external services are added.