The first impression is good, reading the documentation (well written) in a few hour you can understand and define the global structure of the project and you can begin to realize the MVP triplet to fill the regions.

What does it offer?

Four things:
- Modules: the WPF Composite application is divided in modules that you can statically or dynamically loading. Every modules has it’s own view and is does’t know the others.
- Regions: the main window (shell) is subdivided in regions that will be filled by the views defined in the modules.
- Commands: derived from the WPF Commands, Composite Commands add some functionality that permits the communication between Presenters/Views of different regions without build dependencies.
- EventAggregators: where the commands are not enough and you need to communicate with other modules you can use Events to talk.
- (Guidelines): it’s not a documented feature but is bring from the framework itself. The application that you design is well organized and structured thanks to the composite WPF “constraints”.

A sad note. The Composite WPF is known as a “third-party-lib-independent” but removing the dependency from Unity was not simple. We removed it because we want some feature of Spring.NET Framework. IMHO the design here could be better: for example it is better if the UnityBootstrapper doesn’t have a direct reference to IUnityContainer but to a generic interface IContainer that would be implemented using the desired IoC Framework (Spring.NET, Castle, Unity, …).