Decouple or Strong Type?

The Value Object pattern is intended for passing stongly typed data across the tiers of an application. See the EmployeeAdmin demo in whatever language you prefer) for an example of this.

The primary decoupling we want to achieve is to supress model dependencies on the View. Your View has one mission in life: allow the user to interact with the domain model data. So it is understandable that there will be some level of dependencie on Model entities (ie VOs, Enums and other data carriers). However, by avoiding any coupling to the business actors in the view components, we can still see broader reusability in those components.

If you ever want to repackage a view component that relies on a Value Object, it is a relatively simple packaging refactor to put the reusable components and the value objects they depend on into a separate library.

Imagine you're doing a very specialized mapping application, and it uses a lot of corporate domain data. But you realize that the map view component you've built and the VO that carries coordinates, an image url, and some other common map-specific info could be reused, even sold as a separate component. The VO that feeds it is tangential to your corporate domain model, so you package the two in a mapping library and use the library in your app.

The proxies (model tier) of your app work with your corporate data, but also create these map VOs to associate it with the map locations and feed the view with it.

So you've avoided coupling the view component to your proxies, commands or mediators, and thus they can be reused. Your proxies still know nothing about the app they're feeding, only entity data balled up in a VO and tossed to the other tiers.

-=Cliff>