Previously on the Multi Tenancy series:
- Multi Tenancy - Definition and scenario.
- Reviewing Litware HR - P&P Multi Tenancy Sample.
- Multi Tenancy - The Physical Data Model
- Multi Tenancy - Extensible Data Model
- Multi Tenancy - Extensible Behaviors
- Multi Tenancy - Development Structure
- Multi Tenancy - Where do you put variability?
It probably would not surprise you that I a seeing a place for a DSL in a Multi Tenant application. Indeed, one might almost say that I have DSL on my mind a lot these days.
Multi Tenant applications are all about managing variability between the tenants. A sweet spot for a DSL implementation is to manage policy while the application code define the actual operations.
Therefor, it shouldn't come as a surprise that in many instances, where the variability in the application between one tenant and another is entirely (or predominantly) in policy, as it often is, a DSL is a good solution. In particular, defining such things as workflows, attaching behaviors to events in the applications, defining rules, etc. As you can imagine, this is not a single DSL, but a set of languages, each used for a particular task.
I am fond of this approach, for the obvious reasons, but also because it is the easiest way to bring the tenant customization into the tenants hands directly. If you go with that route, you need to be careful about managing the current state (to allow rolling back a changed script) and to ensure that you are isolating the actual application from the client's code, which may very well be written in such a way that would harm the application. As such, it require a bit more investment in the infrastructure than letting developers handle things, but you get a large benefit out of it.