Exactly that. The "middleware" as you put it can manifest itself as one of several things (vastly simplified explanations): 1. Sits in front of your data store

Exactly that. The "middleware" as you put it can manifest itself as one of several things (vastly simplified explanations): 1. Sits in front of your data store and exposes your application's API via HTTP for example. Typical SOA/public API type architecture. 2. Sits inside your web application as a component which you talk to via your internal API. In a Ruby/Python/PHP/Java/C# setting, you would typically have a class with methods on it which correspond to API calls. 3. Ships with your application (if a desktop one for example) and serves an internal API. As above but the component ships with the desktop application. We do 1 and 2 in our product using the same shared components (domain models). In actual fact, it's completely hiding behind NHibernate so we don't actually ever consider the database as part of the problem that needs solving. It's purely where we put our stuff when we don't want it in memory.