I have to design a part of a system in responsible for creating tickets for attractions and then sell them. Basically there are three different parts:
- Product: to create the tickets for sale for each attraction.
- Prices: to assign prices according to some criterias.
- Qutoas: to manage the available quotas.
I have to take care of point 1. Once the ticket is created, other people will be in charge of maintaining its selling prices and quotas.
I am interested in the part of creating and offering a ticket option. The user will be able to see what options are available for a 5 year old child and an adult (or other combination). The system will display a list of all the ticks that meet the search criteria.
Once an option is selected, another process will check if there is a quota and what price it has.
My problem is centered on step 1. Create the tickets.
From the point of view of creation, I think that there is the object Attraction. An attraction can be "Theme Park
X" or a theater show or a museum. The attraction has a configuration that determines which TicketOptions can be created. For example, entry times, person categories by age, languages in case of a guided tour.
So an attraction might have a "General Admission Ticket" that is valid for both children and adults. But there may be a "Park + Night Show" ticket that will be created for adults only.
The Attraction is who has the configuration of how a ticket can be created. Therefore, the attraction would be the root. And it would have a list of TicketOption.
Apart from the creation it is also in charge of invalidating the tickets options created. If the attraction is classified as "adults only" in the future, it'll have to know which ticket exists in order to invalidate those for minors.
The problem is that the application as a whole will actually work with TicketOptions. It doesn't work with Attraction. Everything else is ticket-centric.
My problem is that TicketOption, in the context of creation I see it as a child of an aggregate. But, at the same time, in all other contexts it would make sense for it to be a root.
But if TicketOption has an ID and the other systems reference it. Then I would have an external reference to a child of an aggregate. Which doesn't sound right to me.
Is there any way to solve this problem?