Skip to main content

Fog Carport

Projects - This article is part of a series.
Part 1: This Article

Project Overview
#

Project: Fog Carport Case
Semester: DAT 2nd Semester Exam Project
Focus: Web application architecture, business logic modeling, and workflow design.

This project was developed as part of the Datamatiker program’s 2nd semester exam and is based on a case provided by the Danish building materials company Johannes Fog A/S.

The goal of the project is to design and implement a system that supports the ordering and sales process for custom-built carports. The application allows customers to configure a carport with their own dimensions and submit a request directly through a web interface.

At the same time, the system supports sellers by providing a structured workflow for reviewing requests, validating offers, and managing orders.

The project focuses on modeling real-world business requirements and translating them into a maintainable software architecture.


Vision
#

The purpose of the system is to demonstrate how Fog’s existing manual workflow can be replaced by a structured digital process.

Instead of handling carport requests through fragmented tools and manual calculations, the application provides a clear workflow where:

  • customers can configure and request a custom carport
  • sellers review and validate requests
  • pricing and material lists are calculated automatically
  • orders move through a controlled lifecycle from request to payment

The solution emphasizes a clear separation between customer-facing functionality and internal business logic used by sellers.


Problem Context
#

Fog currently uses an older internal system to handle orders for custom-built carports. Over time this system has become difficult to maintain and no longer fits the way sellers work in practice.

As a result, the company faces several challenges:

  • the existing tool cannot easily be maintained or extended
  • sellers rely on manual processes and calculations
  • the customer ordering flow is not integrated with the internal workflow
  • order information and material calculations are not handled within a single system

Fog therefore wants a modern solution where customers can configure and request carports directly from the website, while sellers manage the order process through a structured workflow.

This project demonstrates how such a system could be designed and implemented.


Business Logic: Carport Order Workflow
#

The application models the process used when selling custom-built carports.

1) Customer configuration and request
#

Customers begin by configuring a desired carport through a web interface.

The configuration includes parameters such as:

  • carport width and length
  • optional shed
  • roof configuration

When the customer submits the form, the system creates a request that functions as an initial offer draft.


2) Seller validation
#

Before an offer becomes available to the customer, it must be reviewed by a seller.

The seller can:

  • validate that the configuration is technically feasible
  • review automatically generated calculations
  • adjust pricing if necessary

This step ensures that all offers follow the company’s pricing rules and construction constraints.


3) Offer presentation
#

Once the seller approves the offer, the customer can view it through the web application.

At this stage the system displays:

  • the selected configuration
  • the calculated price
  • the current order status

However, internal construction details such as the full material list remain hidden.


4) Payment and order completion
#

If the customer accepts the offer and completes payment, the order becomes finalized.

At this stage the system reveals:

  • the complete material list
  • a generated construction drawing (SVG)
  • the full order details

This approach ensures that internal construction knowledge is only shared once an order is confirmed.


Architecture
#

The prototype is implemented using a layered architecture inspired by the MVC (Model–View–Controller) pattern combined with a dedicated service layer.

This architecture separates responsibilities between presentation, business logic, and data access.

The application uses Thymeleaf for server-side rendering. Controllers handle HTTP requests, delegate business logic to the service layer, and return either Thymeleaf templates for rendering or redirects following the Post-Redirect-Get pattern.

The system consists of the following main components:

Controllers

  • handle HTTP requests and routing
  • prepare data for presentation
  • return rendered views or redirect responses

Service Layer

  • implements domain logic
  • performs price calculations
  • generates material lists
  • coordinates the order workflow

DAO / Repository Layer

  • handles database access
  • retrieves and stores domain entities such as customers, offers, orders, and materials

Database

  • relational data model storing application data and order state

This structure ensures that business rules remain independent from both the user interface and the database implementation.


Deployment
#

A deployed version of the application is available online.

Live Demo
https://fog.corral.dk


Source Code
#

The complete implementation is available on GitHub.


Contributors
#

Daniel Hangaard Morten Jensen

Projects - This article is part of a series.
Part 1: This Article