Good piece. I think you're right on, with some qualifications. It sounds a lot like Pat Helland's "inside data" vs. "outside data" distinction, which I find helpful.

A reason to not expose your database is simply because it's hard to control the data format if you need to change it. If you have a translation layer, that translation layer allows you to change the interface without breaking clients--and managing change is (IMO) one of the biggest parts of most architectural decisions. As you point out, in some cases having distinction between public and private data in your data store.

Another helpful idea (which I learned from Udi Dahan) is that your UI--or at least the components of it that are tightly coupled to your data format--should probably be considered part of the service. The term "service" gets overloaded to mean "deployable component" as well as something like "a business capability" that is supported by sofware. In fact, in this conception, a department in the organization--yes, the people!--are considered part of the service.

Anyway, just some quick thoughts. Figuring out how to apply meaningful boundaries is not easy! Thanks for writing-