I would suggest going through the this series of post by Rob Ashton specifically
- http://codeofrob.com/archive/2009/11/01/dynamically-switching-between-master-pages-in-asp.net-mvc.aspx
- http://codeofrob.com/archive/2010/02/08/multi-tenancy-in-asp.net-mvc-views.aspx
However, I think though that you may need to do some overriding of how view names are resolved. The key point I think as noted in Rob's post is that views should be resolved and located in reverse order i.e. always look for views defined for your current site and traverse back to the root where a complete set of views are present.
set of views per unique domain + one
default?
Yes - bearing in mind that you may only need specific views for a domain
use areas?
No - i dont suggest splitting your app up using Areas in this case. I am assuming that you mean an area per domain. You should still split your app into Areas based on functionality and use the same idea resolving the views.
any other idea?
Using Rob's idea is definitely a good option. I would however take into consideration how many domains(sites) you are expecting to have different view for. I am thinking of the case (not very YAGNI) where every area for each site has different view requirements. So i a well thought plan is needed to stored the views. An example of a possible directory structure.
-- Default
-- Area1 // Site2's views rendered from here
--Views
--Shared
-- Area2
--Views
--Shared
...
-- Site 1 // all views from Site 1 are rendered from this folder
-- Area1
--Views
--Shared
-- Area2
--Views
--Shared
-- Site 2 // only view for Area2 are rendered from here
-- Area2
--Views
--Shared