Somehow I had a feeling that metaphor wasn't going to fly ... 
It was a sterling effort though ...
When the penny dropped, I think I 'got' what you're saying the context being the analysis at that point ... My stab at a metaphor would be the 2-D architectural drawings of a 3-D building ... The 2-D Isometric plan view and elevations are trying to convey sufficient information as to establish an understanding of what it is that we are to build ... In this metaphor, one context would be the front elevation, another a side elevation and a final context would be the plan view. Yet another would be the plumbing, another would be the wiring and another could be the heating or air conditioning systems ... It would be from these 'views' that a 3-D model would be constructed.
In a former life I was a mechanical engineer and we'd use 2-D plans to quickly establish an understanding of how to move sufficient liquid around a site (from irrigation to gas refineries). But they lacked sufficient detail for us to carry out a build on a complex system (multi-levels & multi-systems), which is where the 3-D modelling came into its own ... Using the 3-D models, we could spot pipe clashes for example, and work out the loading on the support structures that were to be designed, allowing a modular off-site build to take place.
I'm really starting to understand the difference between a view and a model
As regards the 'inside vs outside' comparison, I'll offer the following instead ...
Using my building anology above, the Domain model now feels like a plan view (in one context), illustrating the perimeter of the site, showing the services to be connected to - sewage, gas, electricity. Another context would show the site elevation, or slope that we're building on, so that we can get everything level and the water doesn't run out of the shower ...
... Another might be the material composition of the ground (a geological survery, equating to an IT Topology), so that we know how deep to drive the foundations and where the water table is ... Whilst the individual views may show some detail of the objects being built - the house, the garage, the swimming pool, etc) - these probably wouldn't be decomposed and would would only be used to suggest 'locality' infomation, such as relative positioning ... Therefore, each view would be a context in its own right, combining to produce a model (a 3-D walkthrough perhaps) against which data can be tested - can we get drain the swimming pool, if we need to, without contaminating the local water supply, or flooding the house? (Top tip: never place a swimming pool on higher ground than your house ...
)
From this understanding, we can then start to dive into the views themselves, and begin to decompose the domain model into the business model. An example would be to decompose the house into rooms (object views), which would illustrate the house as a collection of room objects, each serving a different purpose and containing other objects (i.e. their own contexts). Some may even have relationships, such as a bedroom and en-suite bathroom, the hallway connecting various rooms. On the dynamic side, we have the systems, such as electrical, heating and sewage.
The drawings that I've seen layer the systems over the objects so as to build up a model that we can test with questions, such as, will I have enough sockets in the same location in living room, without relying on extension cables, for my plasma TV, kick-ass sound system and my X-Box?
What's interesting for me is the elegance with which the relationship manifest between the models. For example, whilst working within the business model, I'm starting to get a bit nervous about the number of wall sockets that could be used throughout the house as people plug in their stuff, so I need to ensure that my mains supply is up to the feed. I might need to upgrade my distribution panel and perhaps even feed the house, the garage and swimming pool heating and filter system from the same panel. This could affect the location of the panel.
A reference from the business model to the domain model might be to answer the question, where will be the best place to put my electrical distribution panel? I may wish to have this in the garage and would therefore choose to locate the garage close to the underground mains supply, as illustrated within the domain model. Alternatively, and if I had the budget available to do it, I could have the electricity board come in and extend the mains incommer to where I wanted the garage to go ... But by modelling the project, I can begin to understand the ramifications of various decisions within the project, modelling the outcomes before a single line of code is ever written.
This seems to work for me, but as ever, I'm open to refinements ... I'm really warming to the idea of being an Enterprise Architect ...
