You have already mentioned a pattern for data binding
that access properties and copies data back and forth.
The great thing about this approach is that most people
can will understand it quickly and can work with it
and bind new properties. Also, this pattern provides
a means to buffer data that won't be written back to
the domain if the user clicks Cancel.

On the other hand it's quite difficult to synchronize
data for multiple views.

Another approach is to adapt the domain properties,
here Name and Age, to the model interfaces as required
by the views. The brute for method would require an
adapter for every property. Instead you can use a
reusable adapter that converts domain properties into
a generic format and can use a set of generic adapters
that convert this format into something usable as
models for your views. For example you can convert
bound bean properties into a generic model, let's say
ValueModel (that can just get and set a value)
and use a DocumentAdapter, ToggleButtonAdapter, etc.
to implement Document and ToggleButton for use in
Swing components.

You can then bind a bean property to UI components.
But you still need to create the converter instance
from bean to ValueModel, a converter from ValueModel
to view model implementation, and create a view
using the view model. For example:

Person person = new Person();
ValueModel pa = new PropertyAdapter(person, "Name");
DocumentAdapter da = new DocumentAdapter(pa);
JTextComponent tc = new JTextField();
tc.setModel(da);

Using a binding and component factory you can
abbreviate the above to:
Person person = new Person();
JTextComponent tc = Factory.createBoundField(person, "Name");

The advantage of such a binding is the ability
to perfom complex operations on the value model layer,
for example buffering, caching, multiplexing, etc.
On the other hand, it's more difficult to understand.

If you are short of time, I recommend to use a
simple pattern. If you aim to build many resuable
models and want to present them with multiple views
you may consider using a more complex and powerful pattern.

I'm satisfied with a binding that decouples models
from the views. So I can define almost all event handling
as operations on the model layer. The views just listen
to model changes and present them. I don't need to care
how many views present my data.

Hope this helps,
Karsten Lentzsch