The app is modelled around the following main entities:

visit: this is what is begun by an entry event and terminated by an exit event. A visit that is not terminated is an ongoingVisit. Only ongoingVisits with a parking fee balance of zero can be terminated. Importantly, an ongoingVisit has a timeOfStay property which is the duration between the ongoingVisit's entry and the current time.
payment: this represents a parking fee payment. Partial payments or over-payment are not allowed. Also, a payment for an ongoingVisit expires after a specified amount of time elapses since it was made. When the payment expires, the ongoingVisit it was made for continues to be charged. This is meant to give a person time to exit the parking space while also prompting them to exit soon after making a payment.
parkingRates: this is the data used to calculate an ongoingVisit's parking fee. It is in the form of multiple adjacent ranges over a time scale, each having a fee. It can be represented as below. An ongoingVisit's parking fee is identified by where on the range its timeOfStay falls (the data structure used to represent this is a list of items with the structure { upperLimit: number, fee: number } ordered by upperLimit.)

Parking rates representation — Parking rates data structure representation

Architecture

The app is divided into controllers, services, repositories and entities.

Controllers represent the endpoints of both Modbus TCP and HTTP APIs. The app has controllers for accepting entry and exit event requests, requests for starting and completing (or cancelling) a payment, requests for editing system settings such as parking rates and a few more.

Services contain the app's business logic. There are services for validating and recording entry and exit events, calculating parking fees for visits, accepting payments, and a few more.

Repositories are used for data access. Because this app only has a database as a data source, all the data access is on a database. The app has repositories for storing, retrieving and editing all the mentioned entities and a few more.

The entities, in my mind, are the core of the app. The app gets its essence and definition from them. All other parts are developed around the entities. The main entities in the app are those mentioned above - visit, payment and parkingRates.

Project Architecture — The project's architecture

Tools

The app is a Spring Boot application written in Kotlin.

Most of the app uses typical Spring resources. Spring Web is used for the HTTP API and Spring Data JPA (with Hibernate) is used for database access.

The distinctive part of the app is the Modbus TCP API.

Modbus TCP API

The app is required to communicate with devices that use the Modbus TCP protocol. These are the devices in the parking site, for example, the control device that opens and closes the car park barrier.

After two earlier (and frustrating) trials, I found libraries and frameworks that are easy to configure and that play well with Spring.

I put together a Modbus TCP server using Netty and this very good implementation of a Netty Modbus TCP codec.

Then, for easy integration of the Modbus TCP server with Spring Boot, I used Apache Camel. Apache Camel integrates well with Spring Boot and Netty (I ran the Netty server as an Apache Camel endpoint). It also has a simple-to-use and powerful message routing (which I came to realize is essential of RPC). These two things made it simple to route a Modbus TCP message received from the Netty server over to Spring components and eventually to business logic.

Testing

I tested the app with JUnit 5, AssertJ, MockK, Spring's testing resources, H2 for integration tests involving the database, and Apache Camel's ProducerTemplate for e2e tests involving the Modbus TCP API.