After finishing the database and client networking portion of the assignment, I am beginning to have concerns about the overall complexity of the architecture I've designed. I worried that I might be docked marks for going to far.
Basically along with the low level database I have created a Data Abstraction Layer composed of a FlightDAO (Data Access Object) which handles all persistence related operations. I'm using RMI as the underlying network protocol and the DAO is simply passed a reference to either a DataProxy or Data object depending upon whether local or remote database access is required.
On top of this layer, I have a Business Layer, which handles all the business logic related to searching and booking flight. In this layer I have 2 classes a ReservationSystemController which delegates it's actions to a TravelAgentDelegate class which encapsulates any business logic for searching and booking a flight (e.g., don't book more seats than are available for a flight). It accomplishes this through interacting with FlightDAO passing it Flight value objects for either searching or for booking. When searching, the FlightDAO dynamically constructs queries in the
String format acceptable by the Data.criteriaFind method using reflection on the Flight value object to call the appropriate accessor methods.
My justification for this extensive layering approach is that Fly By Night is a growing travel agency whose persistence needs may soon outgrow their home grown database. In fact, they may even in future move to a web based UI. By decoupling the 3 layers--the persistence access, the business logic and finally the presentation--they should be able to swap to a vendor database or xml persistence engine or Servlet/JSP presentation layer without affecting too much code.
Has anyone who passed gone to this level of abstraction? I'm worried about the statement, "A clear design, such as will be readily understood by junior programmers, will be preferred to a complex one, even if the complex one is a little more efficient than the simple one."
