anomaly2104 / ticket-booking-low-level-system-design

Low Level System Design - Ticket Booking Application Like BookMyShow, TicketMaster, etc.

Problem Statement

Check here

Connect with me and my offerings:

https://enginebogie.com/u/anomaly2104

Video Explanation

https://www.youtube.com/playlist?list=PL564gOx0bCLpAL7yMJqOuK3_hBuLkyRhn

Further Improvements

• Seat type: Silver, Gold, Diamond
  • Different pricing for different types of seats.
• Validating payment in payment success flow.
• Checking if show creation is allowed.
  • This mainly include implementing method checkIfShowCreationAllowed in ShowService.
• Handling different types of movies like 3D, 7D, etc.

ticket-booking-low-level-system-design's Issues

Conflicto con el principio DIP en la clase TheatreService

En la clase TheatreService depende de las clases concretas Screen, Seats, Theatre lo cual inflije el principio DIP. Una solución seria hacer las clases mencionadas anteriormente, en interfaces así la clase TheatreService ya no dependerá de clases concretas, sino unas abstractas.

Conflicto con SRP en la clase ShowService

La clase ShowService tiene muchos responsabilidades, lo cual inflige el principio SRP. Una solución seria dividir la clase, como por ejemplo: ShowService se encargue solo de la construcción y los getters, y la clase ShowServiceValidation valide el permiso de la creación de shows.

Conflicto con ISP en la interfaz SeatLockProvider

La interfaz SeatLockProvider, inflige el el principio ISP, dado que tiene varios metodos que en las clases que lo implementa, no siempre los utilizara. Una solucion a este seria dividir la responsabilidad de la interfaz SeatLockProvider, esta solo se encarga de bloquear y desbloquear los asientos, ValidateLockProvider se encargue solo de validar el bloqueo y otra interface que se encargue de mostrar los asientos.

Conflicto con el principio SOLID DIP

La clase MovieServicie depende de una clase concreta Movie, una posible solución seria hacer una interfaz llamada Movie, de esta manera la clase MovieServicie ya no depende de una clase concreta, sino de una abstracta que seria la interfaz.

Conflicto con el principio DIP en la clase SeatAvailabilityService

La clase SeatAvailabilityService depende de la clase BookingServicie, la solución para este conflicto con DIP, seria hacer la clase BookingServicie una interfaz, de esta manera SeatAvailabilityService ya no dependerá de una clase concreta sino una interfaz, la cual es abstracta.

Conflicto con SRP en la clase BaseTest

La clase BaseTest tiene muchas responsabilidades a la vez, lo que inflige el SRP. Una solución seria dividirla la clase en tres clases mas, como por ejemplo: BaseTestValidation encargada de la validación de asientos disponibles y BaseTestSetUp encargada solo de las configuraciones. Y lo demás en la case BaseTest.