Scott,
I'm curious what your thoughts are on strategy/architecture for handling multi-tenant systems and using an OR/M like NHibernate or EntityFramework? For example, I might want to have 1 Agathas Storefront code base that is shared among different storefronts in the same database backend.

Each Agathas Storefront would have different products, orders, settings, catalog, etc. In the past I have accomplished this by using some kind of top-level DB table and having all the other DB tables keep a FK reference.

For example, 2 DB tables might be:
[STOREFRONT]
Id int PK,
Name nvarchar(500)

[STOREFRONT_PRODUCT]
Id PK int,
StorefrontId int FK,
ProductName nvarchar(500),
Price float

Should the Domain Model be modeled to show/describe the multi-tenant concept? Or should the Domain Model be modeled from the perspective of a single storefront within the multi-tenant system?

Hi ksouthworth,

I am assuming that we are talking about the same company having different shops. Maybe like a smaller version of Amazon that may have different products on Amazon.co.uk to Amazon.com.

With my domain hat on I guess I ask the question:

• Do I care about what other shops sell when customers are browsing the catalog?
  If no then its not a concern of your domain.

With my programmer hat on I ask the following question:

• How can display products specific to my shop that are stored in shared tables with other shops?

If we are just talking about the presentation of the product catalog I would create views for Nhibernate and add the store id in some kind of config file so that it could add as a parameter for all calls for the products.

When it comes to the managment of products then I would have a full blown domain and yes then products do care about what shop they are sold in, or better put, shops care about what products they sell.

I would probably have another table in there as well

[STOREFRONT]
Id int PK,
Name nvarchar(500)

[STOREFRONT_PRODUCTS]
StorefrontId int FK,
ProductId int

[Products]
Id int PK
Name etc..

However if you are talking about creating a product that allows companies without a shop to create an online instance using your software as a service then this is a bit different and your domain concerns are different - what are you trying to do?

Scott

It's more of a software as a service scenario (e.g. Shopify), so each storefront should have no knowledge of the other storefront's settings, products, catalog, etc.