Canem: Pet Walker Booking System

Any marketplace that sells a person's time, from dog walkers to cleaners and tutors, has the same core: a provider says when and where they work, a customer books a slot, and the booking is then paid, rated and reviewed. The hard part is not the screens but the rules around the booking: a slot cannot end before it starts, a review can only follow a finished walk, a rating counts once, and nothing a booking depends on can be deleted from under it. Those rules have to hold whichever screen or client calls the system, so they cannot live in the browser. This project builds that core for a pet walking service in Bogotá, as a team of five over one semester.

The system is three tiers with calls in one direction: a browser app, a REST API, and a layer of rules over a relational store. The booking is the centre of the data model: each one ties a customer, a walker, a zone and their pets to exactly one time slot, one payment, one rating and one review, so every rule is checked against a single record. The URLs follow ownership, so a walker's slots live under that walker, and the API confirms the parent exists before it touches the child. Every rule sits in one layer of stateless services that turns a violation into the same clear error, tested inside a real application server while recorded API calls replay each resource's contract.

• Learning

  The booking as the aggregate

  Making the booking the record that owns its slot, payment, rating and review gives every rule one place to look: one rating per booking, a review only after the walk, no deletion before it is paid and finished. Without that anchor the same rule gets checked in several places and the copies drift apart. This is what lets a marketplace add a new kind of charge or feedback later without auditing every screen that touches a booking.

• Learning

  Rules in one layer, errors in one shape

  Validation in the browser protects one client; validation behind the API protects all of them, including the ones not written yet. Putting every rule in stateless services and mapping every violation to the same HTTP status with a readable message means a mobile app, a partner integration or a test script all get the same answer. That single contract is what lets several teams build clients against one backend in production.

• Learning

  Tests at the boundary a client sees

  The rules were tested twice: 168 tests run the rules and data layers inside a real application server, and recorded API calls replay each resource's contract, expected status codes included, against the running service. Tests at the boundary catch what unit tests miss, from a wrong status code to a broken mapping between a record and its JSON. They are what let several people change the same API in parallel and find out before a client does.