views:

53

answers:

0

We have a product where the infrastructure/application and UI code is generic for the most part (some views may have to be tweaked but this is only in spark files). The domain model however may change from client to client and this needs to be easily swapped out and replaced with an assembly with potentially more properties/data on the entities, never less.

My question is in the scope of physical layout. We are applying DDD to this domain as it is extremely complex, and as such the domain model assembly doesn't depend on anything other than the BCL and one or two supporting tools. We are using visual studio 2008 for development.

At the moment, we have the domain model assembly being pulled into consuming assemblies via assembly reference and the dll being dumped in a specific spot on each build that every other project can then reference and use to compile.

Is there a "best practice" or an easier way to accomplish this other than assembly references? It seems if you use project references you are bound to a specific version of the outputted assembly, while assembly references you can set SpecificVersion=false to get around this. What we don't want to do is have a new solution file created for every client, although this may be the easiest way so that our build server can just target the specific solution file. Seems like a little overkill however.

As we accrue more and more clients there is the potential to have a specific domain model assembly for each client and I want to make sure we can address and manage this requirement properly. Has anyone else done something like this?