Let me begin by saying that Prism does not strike me as being easy stuff.  Maybe it's not supposed to be, but there's nothing here that seems to make it any easier.  The fact that the instructions begin with hunting down the projects, building it (couldn't I just pull the dlls directly?) and then adding a number of references that I can't say that I fully grok.  Part of the problem is likely that I'm actually exploring the MVVM pattern and the Unity IOC container at the same time, but there's a lot here for what seems like a simple, but very significant gain.  The significant part excites me.  I don't think it's just a testing thing either; the notion of being able to write modules in a complete but separate way and then attach them to my application appeals to me for my current project specifically.  I think it's less about making some kind of custom version for different people (neat idea, but not something that I need) and more about separating the project into parts that are easier to digest.  My prototype, limited as it was, still got way too long and complicated and was difficult to follow by the end.  Breaking things down into smaller files just meant that I had to have all the files open in order to follow it.  By separating things into modules, I am certain that each module is self-contained and so, if I can't understand it, the problem is with that module, not the whole program.  I acknowledge that I may look at this later and decide that I don't really get the advantage the Prism gives me.  That's ok; I'm happy with the value I see in it now and that should let me go further.

So here's the flow as I understand it.  Assuming I have some data object that I want to use, I need a service that returns that object (or a collection of said objects) and an explicitly defined interface for that service.  The interface part seems the most unfamiliar to me, though I don't do a lot of testing/mocking of simple objects like this and I really do see the value in defining things this way (being able to swap out the real service for a mock one so you can test it).

The View Model is where it gets fuzzier for me.  It might be because Silverlight doesn't have a notion of Commands (WPF does) and so I've gotten used to programming without them, which unfortunately means that you're either writing the implementation of a command into the code behind itself or you're creating a hard link between the implementation and the actual UI Event.  What gets me is that the View Model is still pretty View specific; I don't see (yet?) how I could write some kind of generic View that could might work for different View Models.  Maybe that's something I'll get to later.  Still, I get the flow of it.

The magic seems to be in the module class itself.  This provides a concrete link between the data access service interface and the data access service object (this is where I would swap them out for testing).  It also registers a region (an empty space inside the main visual tree) as containing this specific view.  The first seems to be the Unity side of things, while the second is definitely the Prism side.  Even if I were to get sloppy with the IOC side, I think the notion of creating regions and filling them with module Views makes sense.

The shell then needs to have a catalog of modules (I added it with a direct reference, but I can see how you might set up some kind of watcher on a directory and then load the assemblies and add them dynamically).  In this case it's created in the bootstrapper (part of Unity) and the entry point for the application looks like it moves from App.Run() to Bootstrapper.CreateShell() and Bootstrapper.GetModuleCatalog().  I'm still looking into how modules will talk to each other, but I can see how to create a tray full of widgets and how one might swap widgets in and out dynamically.  There's certainly more; I'll keep exploring the framework and expand on this when I figure it out.

I did write code for this, by the way.  I went through Erik Mork's excellent video and made some small tweaks to what he walked through.  I really get a lot of value out of typing things in myself, even if the only changes I were to make were just changing the names of a variable or two.  There's some kind of 'coding muscle memory' that goes along with actually having to create the classes, add the references, add any using statements, and actually write out the code.  I wouldn't say that going through it once means I'll remember it, but it's far better than just reading the code.  The only reason I'm not posting it here is because the description goes a lot further than the actual code does.  A good exercise overall.