Domains

Introduction

Our platform’s purpose is to “enrich the lives of people everywhere by connecting them with exceptional things to do”.

At its core, we operate a marketplace that brings together supply (the experiences and activities available) and demand (the people seeking those experiences).

The system’s architecture, as well as the way information is presented in our administration tools, is organised into domains. A domain represents a logical grouping of related data.

For example:

• The Product domain contains details about attractions, tours, restaurants, and other experiences people wish to enjoy.

• The Consumer domain holds information about individuals and the trips they are planning.

Naturally, running a marketplace requires managing far more than just consumers and products. We also maintain data about our partners, the channels and brands they use, the destinations we serve, and much more. This documentation outlines the overall structure of these domains, explains how they interrelate, and describes how our administration tools enable users to navigate and manage domain data efficiently.

Entities

We use the term “Entity” to refer to any individual “thing” within our system.

For example, in the Product domain, we store information about every product available. Each product can be referred to as either “a Product” or “an Entity”. Similarly, an individual Consumer may also be described as “an Entity”.

When using the Administration system, you will typically be viewing the Navigator for a single Entity—whether that is a Product, Consumer, Booking, or any other item in the system. The Navigator (explained in the next section) displays details about the selected Entity, as well as any Entities in domains that are owned by it. This includes the ability to move down the hierarchy to view or manage related, lower-level Entities.

In summary, an Entity is any distinct item in the system, and the Administration tools are designed to help you view, manage, and navigate between these Entities through their relationships.

Navigators

The administration system presents domains via a set of screens known as “Navigators”

Navigators serve the following purpose

• To provide an overview to the user of the given entity

• To allow permitted users to view and edit and take action on the data for the given entity

• To provide the user with the ability to search, filter and report on data in any domain owned (directly or indirectly) by the given entity

• To provide the user the ability to navigate to the Navigator of any domain entity that is owned by the current entity

Direct (owning) Relationships

With data organised into domains, it is essential to understand how these domains relate to one another. These relationships often represent “ownership” of data, where one record in the system may “own” other records.

For example, a single consumer may take multiple trips over several years, each to different destinations and possibly with different companions. In our system, the Consumer domain stores information about the lead passenger, while the Consumer Trip domain captures details such as destination and dates. Within the administration interface, viewing a consumer’s profile will display a list of their trips. Navigating to a specific Trip updates the breadcrumb trail to reflect this relationship (e.g., Home > Consumer > Trip).

As our platform supports multiple partners, it is also important to track which business entity “owns” a consumer. Some domains are classified as Principals—business entities that either work directly with us or with our partners. The highest-level principal is “The Company” (Holibob), beneath which are Partners (directly contracted entities), and under them, Channels (brands or sub-entities of a partner). The administration system allows users to navigate this hierarchy, which is reflected in breadcrumbs such as Home > Company > Partner > Channel.

Bringing these relationships together: a trip is owned by a consumer, a consumer is owned by a channel, and bookings are made in the context of a specific Trip. This hierarchy is represented in the administration interface as Home > Company > Partner > Channel > Consumer > Trip > Booking, making data ownership and navigation clear and intuitive.

Indirect Relationships

So far, we have understood that data within one domain in the system is typically “owned” by a higher-level domain. It is clear that the administration system allows users to traverse this hierarchy of ownership to arrive at a given record.

In the examples so far we can understand that a user starting at the level of “The Company” can navigate via Partner and Channel to a list of Consumers and onwards to their Trips and Bookings. The user is following the path of ownership.

This, however, does not serve well when an administrator is seeking direct access to Consumer Trip or Booking for which they have the id or code nor for finding a Consumer with a known email address or name. Equally, it does not allow a user to search, filter or report on all the bookings that may lie beneath a given Channel as the bookings are not “directly” owned by that channel.

The concept of Indirect relationships is inferred from the existing data. It is the case that all of the Bookings owned by any Trip, Consumer and Channel of a given Partner are indirectly available to that partner.

Indeed, it is inferred from that data that ALL data is indirectly available to The Company.

Indirect relationships are represented in the administration system through the lists that are available within any given navigator. Thus the Partner navigator may contain a list of indirect Consumers and indirect bookings thus a user on the partner navigator can query and report on all of the data that lies anywhere below their own level.

Users & Principals

Access to our administration system is always subject to authentication.

A user will always be associated with one of the following Principles.

• Company - These users are part of the Holibob internal team.

• Partner - These users have oversight of the whole Partner, including access to all channels.

• Partner Channel - These users have oversight of a single Channel.

• Agency - These users are typically sales agents who book on behalf of, or provide support to, Consumers of a given Channel or Agency.

• Supplier - These users are typically involved in uploading and managing internal products for a single supplier.

All users are configured with a set of permissions that control the screens they can access and the actions they can perform.

All users are also subject to an access level that may further restrict the records that they can see across the screens they have access to

User’s Landing Page

Users will typically be landed on the Navigator that corresponds to the Principal they are associated with. Thus, for a member of The Company, they will land on the Company navigator, whilst a member of a Partner Channel will land on the Channel navigator.

Subject to permissions, any user will be able to navigate from the place they land to all lower levels across the system, but they will never be able to traverse upwards from the place they are landed.

Thus, a member of the company may, subject to permissions, traverse the entire system, and a member of a Channel will never see information at the level of their Partner, nor any other partner.

For the given user, this landing page will be presented in the Breadcrumb as Home >

Domains

The following sections providefurther details about each domain in the system.