We know the "Flight" class in the bussiness domain model, but it can't represent origin flight data. It means the flight of prepared itinerary. Am I right? Then my question is that should we design the origin flight data or just design a DAO class to wrap all the bussiness logic?
In general, business logic inside a DAO is not recommended approach. A Data Access Object is meant to manipulate database access in a separate layer. I suggest you to look into DataAccessObject pattern at :
IMO, the Filght and associated business domain classes can be used for two purpose: one for Itenerary, one for flight catalog. Admin provides new filghts to the the catalog. Cuctomers search the flights in the catalog using DAO and may have some kind of cache, but book a flight using entity beans(updating happens on both Itenerary and catalog side). after a flight taking off or any other reason to be unavaible, a status flag changed and the data becomes historic.