holiday-property-booking/02-content-architecture-and-data-model.md

02. Content Architecture and Data Model

Purpose

Define the information structure behind the public site and admin area before implementation begins.

Scope

• Public pages:
  • homepage
  • listing page
  • property detail page
  • contact page
  • editable content pages
• Core business entities:
  • property
  • property image
  • amenity
  • pricing rule
  • availability block
  • booking
  • payment
  • enquiry
  • testimonial
  • content page
  • site settings

Proposed Content Architecture

Public Content Layers

• Global site content:
  • brand name
  • logo
  • contact details
  • social links
  • footer content
  • site-wide SEO defaults
• Marketing content:
  • homepage hero
  • testimonials
  • feature blocks
  • location highlights
  • FAQs
• Property content:
  • title
  • slug
  • summary
  • full description
  • location text
  • capacity details
  • amenities
  • gallery
  • house rules
  • check-in/check-out times
  • pricing summary
  • availability data

Core Entities

• Property
  • published status
  • featured status
  • slug
  • summary
  • long description
  • sleeps
  • bedrooms
  • bathrooms
  • pets allowed flag
  • minimum stay rules if needed
• PropertyImage
  • property relation
  • alt text
  • display order
  • primary image flag
• Amenity
  • name
  • icon/label if needed
  • property relation
• PricingRule
  • property relation or global relation
  • base price
  • seasonal overrides
  • weekend override
  • guest-based adjustments if needed
• AvailabilityBlock
  • property relation
  • start date
  • end date
  • reason/status
• Booking
  • property relation
  • customer details
  • dates
  • guest counts
  • price totals
  • booking status
  • payment status
  • timestamps
• Payment
  • booking relation
  • Stripe identifiers
  • amount
  • currency
  • status
  • webhook event tracking
• Enquiry
  • property relation optional
  • customer details
  • message
  • timestamps
• Testimonial
  • author name
  • content
  • rating if used
  • publish status
• ContentPage
  • slug
  • title
  • body content
  • SEO fields
• SiteSettings
  • business details
  • booking rules
  • default SEO
  • email settings references
  • social links

What Needs to Be Done

• Define the entities and their relationships.
• Define which fields are public, admin-only, or system-managed.
• Identify which content is reusable across pages.
• Define the minimum data needed to support the booking flow and SEO pages.
• Identify any content that should be seeded versus manually managed.

Entity Relationships

• A property can have many images.
• A property can have many amenities.
• A property can have many pricing rules.
• A property can have many availability blocks.
• A property can have many bookings.
• A booking can have one payment record.
• A property can have many enquiries.
• A content page is standalone but uses shared site settings.
• Testimonials are site-level content and may optionally be linked to a property.

Acceptance Criteria

• The project has a clear content model.
• The admin-managed content is separated from the public-facing content.
• The model supports multiple properties without special-casing one-off pages.
• The data model is sufficient to support the later booking and admin docs.
• Relationship ownership is clear enough to implement later without reinterpretation.

Dependencies

• Intake and scope approval.

Notes

• If a field is uncertain, it should be marked for decision instead of guessed.