To use this strategy, you will still have to change the encapsulation and make bar public.

That being said, if having an object create representations of itself gets too complicate, either messages or for the UI, then I would try to split it out in some way (like using presenters for views).

In general, I dislike using reflection in java. The reason we suffer it’s verbosity is for it’s static analysis and typing, and if we take that away, we end up with some half crippled bloat language that doesn’t do either static or dynamic well.

In practice, I

a) rarely rely on one pattern to guide a design (no, really Mark), or
b) consider design to be a static thing.

So if you can evolve comfortably from literal message creation to domain model, then you’re going in the right direction. Whatever path you took to go there will be reflected in your design. Each path is valid.

My main concern is that you focus on one design pattern. I think that having parallel class hierarchies is a smell. If I find myself creating class A and class AMapperForSystemX, and AMapperForSystemY, I’ll probably look for duplication, and remove it.

DRY may be SRP’s natural enemy…

However, I think it’s fine to use mappers too, except I’ll delegate to a communication strategy:

class A {
CommunicationPolicy cp;
populate( Message msg){
cp.populate( this, msg )
}
}

Does it just mean I have to encapsulate what I mean by “One thing?”, so rather than “it changes if A or Msg changes”, I phrase it as “it changes if the relationship between A and Msg changes” (which is still one thing).