Preliminary remark about your approach: caution !
Starting to model a specific domain (e.g. airline ticketing) is challenging. Trying to abstract a part of this model for later potential reuse (e.g. railway ticketing, olympic game ticketing, hotel booking, etc...) comes with three significant risks:
- Communication risk: your model will be more difficult to share with the business experts. They might get confused with your abstractions. This might quickly result in the feeling of not being understood, and tensions might arise.
- Accuracy risk: the business experts will naturally mentally map your abstract ticketing entities to the concrete concepts that they use in their daily life. If you don't catch the consequences of this semantic confusion, your abstract layer might quickly end up to be very specific.
- Project risk: by trying to deliver two things at a time, i.e. an abstract engine, and a concrete adapter for it, you may be confronted with lots of additional issues that might jeopardize your main project.
When to do it ?
If the abstraction is done only for the purpose of a generic implementation, my advice would be to use another approach: first take care of your initial ticketing system and keep the domain model clean, then refactor.
Nevertheless, ticketing is a business domain of its own. And some practices cross the borders of their original industry. For example, in Europe, many railway companies have adopted airline-like ticketing principles (and systems). Some general problems like dynamic pricing, yield management, etc... are even recent innovations that are worth to be handled as original business concepts.
So, if your abstraction is in fact about modeling a more general business domain, with a buisness value of its own, your approach could definitively be justified.
How to do it with DDD ?
The situation that you describe is in fact quite common in large and compex projects: several domains may have to interact. Evans addresses it explicitly in his big blue book:
Bounded context: The delimited applicability of a particular model. BOUNDING CONTEXTS gives team members a clear and shared
understanding of what has to be consistent and what can develop
independently.
Interestingly, in the part about strategic design, in chapter 14 he gives as example a shipping business, and identifies booking system as a distinct bounded context.
The principle of bounded contexts is that there may be several domain models, each defined in a bounded context. The ubiquitous language applies within a context.
In order to keep the overview and ensure consistency, a global context map shall depict the main concepts of the different contexts, and map across the boundaries the related concept:
Context Map: A representation of the BOUNDED CONTEXTS involved in a
project and the actual relationships between them and their models.
If the above link to Fowler's article is not sufficient, I'd recommend you to read more about this topic in Evan's book. It's definitively worth its money, if you're professionally using DDD.