Is there a good design pattern for keeping object between layers decoupled?

I think this is a common design problem, but I keep scratching my head every time I face it.

On one side, we have our API which sends or receives simple structures aimed to be consumed by web apps, mobile etc. We could potentially have multiple APIs aimed for different devices. On the other side we have our internal domain model which may or may not match the data store entities.

Let assume the following POJOs to assist the discussion.

@POST
public addBlogPost(BlogPostApi blogPost) { ... }

// api model
public class BlogPostApi {
  ...
}

// domain model
public class BlogPost {
  ...
}

// db model
public class BlogPostEntity {
  ...
}

First, we could use the same model in all three layers. While that could be a solution for very simple services, it's usually not a good idea since all the layers are implicitly coupled. So, I'll assume we want to use a different model object per 'layer'.

One approach I've seen widely used is to create adapters between layers. While that solves the problem, it creates an explosion of classes you need to maintain. In the (common) case when you add a new field to the data store which needs to get exposed on the UI as well, 3 POJOs + 2 adapters need to be changed. There's always the risk of forgetting to change one of those. This process could be automated slightly, with the use of an object mapper library.

Another approach I've heard is the use of interfaces. Two or more classes implement the same interface which exposes the get/set methods for 'common' fields. This removes the risk of forgetting to change something, but it creates coupling. Also, I find this use of interfaces wrong, since interfaces should expose functionality.

I'm leaning towards the object mappers. Does anyone know of a design pattern or solution for this problem?