I was watching one of Uncle Bob's videos and he brought up the Database Interface Layer.  He had this diagram showing it:These arrows show that the DB Interface Layer is aware of and calls the Application and Database layer, but not vice versa.  The DB Interface Layer has data records in it.  These are classes that have the name of the table and the fields of the columns.  These are what I usually call DTOs.  But these data records have all public fields and no/few methods.  The DB Interface layer is responsible for grabbing the data from the database, populating the data records and implementing an interface in the Application Layer like so:I'm a little confused because I've never heard about this separation before.  Every project I've worked on uses the DTOs in the view which is apparently wrong (at least according to Uncle Bob's video).Also, I've never worked on a project where the DB Interface Layer calls the Application Layer.  It's always the Application layer asking the DB Interface Layer for information.  For example, by using a DAO.  But this is starting to make sense.  Whenever I use hibernate I'm always pulling my hair out because I try to make the DTOs more OO and the library always fights me.  So, I guess what I'm trying to ask is, what does the code look like on/at the boundary between the Application and the Database Interface Layer?  For example, how does the Application get the implementation of the Order Gateway Implementation?  Is the Order Gateway Implementation a DAO?  I don't have a clear picture of how the POS can use the Order Gateway vs how/when the Order Gateway gets populated with data.
How do the Application and Database Interface Layers interact at their boundary?
design patterns;programming practices;enterprise architecture;layers