Architecture Patterns For Booking Management Platform

Abstract –Booking management is the most important part in customer journey, the core of any business are bookings and booking management. Even slightest outage or disruption in this service could cause significant financial loses and impact on customer trust. Therefore reliability & scalability must always be taken into account before designing any booking management solution.

This article present detailed Basic Principles, patterns and high-level design of a booking management platform.

Index Terms — Performance, Designs, Reliability, Business Logic, Monitoring. API, DDD, EDA, Microservices.

INTRODUCTION

As most of the companies are going through massive digital transformation moving our products, processes and services online. We build e-commerce websites, we move our documents and storage to the cloud, we build apps, platforms and make everything faster and more accessible.

Before we dig deep into this particular solution related to booking management platform, first we must make clear that what Booking management is and what booking management is not.

· Booking management solution provide global view of any product which can be sold on any digital channel.

· Booking management solution will enable us to integrate easily to any target solution such as CARS, CRM, etc.

· Booking management give one single entry point to manage bookings to any digital channels.

· Booking management solution will enable us to design and support our financial processes.

· Booking management solution will be also used to bundle different products (Transfer, Activities, excursions, etc.) where necessary.

NOT’s of Booking Management:

· Booking management solution is not used for any supplier and client invoicing but rather store information shall be used

· Booking management solution is not based to resolve one specific problem.

· Booking management solution is not based on any specific technology but on specific architecture principles.

Architecture Approach

This section speaks of architecture approach which we have taken into consideration while designing the solution in order to deliver business requirement & value: there are many approaches that can be taken in order to deliver the solution but this article only explain the more simple and achievable approach, in this approach the solution will heavily rely on orchestration (Event Driven) pattern, domain driven design and micro services architecture principles.

Take always into consideration architecture approach that enables computing components or layers to execute independently while still interfacing with each other. Main focuses on the generation and handling of event notifications. This concept defines strongly flexible architectures, in which the elements generating event notifications do not need to know the receiver components. In addition to that, an event-driven architecture has not a deterministic response time for processing input events, but it is much faster adapting to changes. This paradigm makes possible to create real-time responsive and decouple architecture.

Microservices communicating using event service bus

So What is an event?

Simply put, the event is a significant change in state, which is triggered when a user takes an action.

For example:

1. When a customer buys an excursion and its state changes from For Sale to Sold is an event.

2. After a successful transaction, when an amount gets deducted from your account is an event.

3. Once clicking on the book button, when it is booked from your account is an event.

Every event may trigger one or more than one options in response.

Event-driven architecture components:

An event-driven architecture typically consists of four components:

1. Event

The significant change in the state of an object that occurs when users take action.

2. Event Handler

A software routine, which handles the occurrence of an event.

3. Event Loop

Event loop handles the flow of interaction between an event and the event handler.

4. Event Flow Layers

The event flow layer is built on three logical layers: Event Producer, Event Consumer, and Event Channel (also called Event Bus).

• Producer which is responsible for detecting and generating events.
• Consumer which consumes the events produced by the event producer.
• Event Channel which transfers events from the event generator to the event consumer.

Second pattern which is the most important in this design is DOMAIN DRIVEN DESIGN

To define domain-driven design we should first establish what we mean by domain in this context (and in development in general). As per our any DOM (digital operating model) booking management is vastly agreed Domain.

so what is a Domain?

the common dictionary definition of domain is: “A sphere of knowledge or activity.” Drilling down a bit from that, domain in the realm of software engineering commonly refers to the subject area on which the application is intended to apply. In other words, during application development, the domain is the “sphere of knowledge and activity around which the application logic revolves.”

DDD focuses on three core principles:

• Focus on the core domain and domain logic.
• Base complex designs on models of the domain.
• Constantly collaborate with domain experts, in order to improve the application model and resolve any emerging domain-related issues.

Modeling a system

So within the context of EDA and DDD design the solution using micro services. Bear in mind there is no rule or written principles where and when to use such architecture but recommendations only, within our company it’s been commonly used and we have all the expertise in order to develop any large or medium size solutions based on this architecture. Please see below some real reason of using microservices:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organised around business capabilities.

N-Microservices within one Business Domain

Mainly microservice is composed of the following.

— API Layer

— Business Logic Layer

— Data Base Layer

So now that architecture approach patterns are established where we have made clear WHAT and HOW we will be able to reuse the functionality exposed by different layers. We will be able to distribute layers over multiple physical tiers. This can make a very good impact on performance, scalability and fault tolerance. Adding more functionality on any layer without any global deployment and make easier for testing independently.

Booking Management High Level Architecture

This part explain propose solution in reference with defined architecture approach and patterns.

This architecture is divided into 3 main layers:

• Digital channels (Sales)
• Booking API & Business Logic
• Source systems or Subsystems

All digital sales channel will only use one single booking API which will be expose by booking services from the business logic layer. Through the same API it will be possible to perform any booking or post booking operations (Cancel, etc.) and also can be used through a backoffice.

In business logic layer, it is possible to send corresponding booking request to target systems using our established EDA pattern. In such way we are able to decouple main booking services from target systems and their existing logic. Same layer we can store all bookings and assign one single unique identifier and all sub-product bookings is store under this reference.

Any other system such as, Data Hub, Finance Hub, CRM are also integrated with the main booking management system in order to get any relevant information for each system usage.

Conclusion:

Let the innovation start in the mind, then reflect in the business.

In the context of Digital Transformation, it refers to the rapid speed of change we are currently experiencing. The digital revolution is powered by technology — the internet, mobile technology, computer processing, artificial intelligence, machine learning, nanotechnology, robotics and information processors are all tools that we can use to perform tasks in different ways.

Modern technological advancements have without question changed and shaped the world we live in, but we usually fall into the trap of thinking the technology itself is the driver of change. It’s not. Technology provides the means by which jobs/tasks can be carried out. Technology gives us new capabilities. Technology is just a tool to deliver business value and provide best services to our customers. So use it wisely and never be afraid of trying new patterns or designs but always keep the purpose in mind why we are designing it and what benefits we will get out of it. Choose simple solutions.