Balancing Variability & Commonality

When creating a DSL (Domain Specific Language) one of the most important choices is to decide about what items in your domain are going to be considered variable, changeable and which ones are going to be considered fixed, carved in stone.

The former need to be specified in your DSL, in your design or may be coded. The latter are considered immutable and will remain static for all your derived applications for ages.

Considering that everything is static it is obviously useless. On the contrary, considering every aspect variable drives to another no-end getting nothing tangible again as a result. Therefore, in the middle we will have to search for the virtue.

The main issue here is to study a domain and ponder between variable parts and fixed parts. It is not a trivial thing to do from the very beginning. Experience in DSL construction and specially, experience in the domain helps to train your smell, but there are not clear rules for it, nevertheless.

It is not only about knowing your requirements. It is about trying to predict how your requirements will change across time and what types of requirements have more likelihood and tendency to change.

Adding variability

A variable part could be, for example, the background color of your application. If so, you need to add syntax and semantics to your DSL to capture such property. Let’s say you can express somewhere in your specification:  { background-color = peach; }

We can select the peach color for app1, and may be ivory for app2.

However, nothing is for free and this freedom comes with the followings possible drawbacks:

  • You need to increase the size of your language (DSL), editors, model checkers, compilers and code generation or interpreters.
  • Users have to provide a value for such property unless you have also provided a sensible default value in case of missing information.
  • Homogeneity across applications vanishes with respect to background-color. Now it’s a user choice (the one in control of the modeling tool).
  • Specs are more complex.

Adding commonality

On the other hand, if you consider the background of your application should be always the same because you are following, for example, a user interface style guide then, the background color is a fixed issue. Its value is provided by design by a style guide, by an architect, or design choice and the user modeling has no control over it.

In this scenario, the DSL is smaller. No need to specify the background color, it is implicit, it is no included in the model/specification.

With this kind of choice, we are betting for standardization. A shared library, a runtime framework or an interpreter will take care of supplying the right color in the right moment.

  • Users can not change the background color, specs are smaller.
  • Standardization is improved across applications.
  • User has no control on the feature.

But, what is the right choice?

It depends. There is no right choice with the information given till the moment. To answer the question we need to consider if the background color is a fundamental feature in our domain and it is needed to be different from application to application or may be, on the contrary, the color should be used in an homogeneous way following a predefined style guide.

Again, the domain imposes the rules to follow. Studding the domain and its variability is crucial to create a consistent DSLs focused in gathering the key features of the domain in a model: the important and variable ones. The important and fixed ones must be also identified but they shouldn’t be included into the model, but into the framework or the runtime.

Standards, policy assurance, compliance

Everything related to standard procedures, compliance and in-house stile guidelines are first-class candidates for standardization. If done in that way, your developers will not have to remember all that weird standard and compliance rules when developing a specific artifact.

A code generator will provide the right value for them. It will do it silently, without errors neither oversights. All the boring code dedicated to plumbing applications like: naming guidelines, service publication, serialization, persistence, adapters, proxies, skeletons, stubs, DAO code are driven by strict standards and best practices and are natural candidates for strong automation by code generators.

Moreover, if the regulation or the standard changes, the change will have impact in the following assets:

  • a single change to a framework will be enough
  • or a change to a code generator and then forcing a regeneration process and redeploy.

In both cases, it is cheaper that manually reviewing a set of in-production applications.

For example, think about replacing your data-layer access code from a DAO pattern and SQL to an ORM based approach like Hibernate.

Business Know-How

The core of the business Know-How is the important and the variable parts we are interested in to be collected in a specification. Such features need to be modeled, and if possible, abstracted from the technology that will implement it.

If we do it in this way, the model can survive the current technology.

Why we could be interested in do it in such a way?

Just because technology evolves like fashion. Today everyone likes red T-shirts, tomorrow blue jeans will be sublime! Basic, Cobol, C, Java, C#, Ruby… what is the next language to use in 5 years time?

Use your best bet, whatever platform better fulfills your requirements, but I it could be nice to see the business process surviving the technology. 😉  We don’t know in which direction, but technology will evolve, and will change for sure.

Maintaining a language or a DSL

When a DSL or a language needs a review you will be probably considering adding new features to the language.

Each new feature will increase the variability and increase the complexity of the language. Before deciding to add a new modeling feature make a cost/benefits analysis and double check that the valued added by the improvement is greater than the cost of implementing it.

I like to follow the golden rule proposed by Gordon S. Novak about automatic programming:

“Automatic Programming is defined as the synthesis of a program from a specification. If automatic programming is to be useful, the specification must be smaller and easier to write than the program would be if written in a conventional programming language.”


Whenever is possible:

  • Business Know-How should be captured by models, specs, DSLs.
  • Technical Know-How should be captured by code generators, model interpreters, best practices and patterns.

So, at the end of the day I like the following pair of quotes to sum up about what to include in a model:

  • The Spanish writer Baltasar Gracián in the XVII century said “Lo bueno si breve, dos veces bueno.” (a literal translation from Spanish could be: “Good things if brief, twice good.”)
  • On the other side, Albert Einstein (XX century) counterpoints “Things should be as simple as possible, but not simpler.”


  1. […] This post was mentioned on Twitter by Jordi Cabot, André Dietisheim. André Dietisheim said: RT @atomweaver: Balancing Variability & Commonality in DSLs : #dsl #mdd […]

  2. Interesting post.
    Nevertheless, sometimes the variability is linked to a business element (defined in your “business” model) but is too technical (it can’t be integrated to the “busines” model). For example, the DB system could be Oracle or SQLServer. To generate the right DDL and corresponding DAOs, your generator needs to know the target. A solution consists in creating an additional “technical” model, referring to the “business” model and defining the “technical” variability. It is, for example, the strategy used by EMF by separating the ECore and GenModel.

  3. Thank you Fred for your comment. I fully agree with you.

    In such cases, the level of abstraction of the features been introduced is the main driver. Here Separation of Concerns calls us on splitting the what from the how in a clear manner. Probably such design choices are not going to be comfortable in your abstract DSL, and moreover, the person in charge of setting them up is probably different (more technical) than the person using the abstract DSL.

    As you suggest, one alternative would be to add an intermediary design model if the design choices are important to be carefully fine tuned before going directly to code generation. MDA terminology also calls this PIM (Platform Independent Models) and PSM (Platform Specific Model).

    Another alternative could be to offer such design choices as generator settings (if they are not too complex) and/or add sensible default values following a Convention over Configuration pattern (à la Ruby on Rails).

  4. I usually use PSM terminology to define models derived from a PIM by applying technical projection strategies : the PSM is a result. I think the strategy itself should be composed of a static part contained in the generator (or PIM to PSM m2m transformation) and a framework, and a variable part expressed in a complementary DSL interpreted by the generator.

  5. OK, that’s a sensible approach.

    The focus on my comment was about what you call the variable part expressed in a complementary DSL interpreted by the generator. This kind asset could be as simple as some pairs of key and values to express global generation settings, but also could be complex enough to be considered by itself as full design models to fine tune the code generation process depending on the project needs.

    Nice to share point of views on it. Thxs Fred!

  6. This is a topic that is under study since years now under the terminology: Software product line engineering.
    The creation of MDA at the OMG was partly due to the work being done at that time in Europe and with the SEI in the US.
    product line engineering is based on two processes: Design for reuse (show variability) and design with reuse (make decision concerning variability).
    Of course depepnding on the MDA kind of model you are using the variability type is different. MDA was supposed to manage platform variability (from PIM to PSM).

  7. Social comments and analytics for this post…

    This post was mentioned on Twitter by atomweaver: Balancing Variability & Commonality in DSLs : #dsl #mdd…

  8. Pedro, an interesting take on an old subject of engineering good quality DSLs. In particular, I was triggered by your section “But, what is the right choice?”. Working with MDE since 2000 and haven had attended many MDD/DSL workshops, trainings and events, this question has been in my experience the most difficult and frustrating. (And I believe that many attendees felt the same way too).

    Business requirements (if an MDD project is lucky to have such things) are often not good material to answer the question. <- One might have a better chance of understanding a domain (be it business or technical) by reading Wikipedia instead of studying requirements! 🙂 I am convinced that good skill in Domain analysis is indispensable in an DSL project.

  9. Good point Andriy! Full agree!
    No matter what tools people use or how much agile they are. If they cannot understand the requirements, and here Domain Analysis is crucial, they are doomed to fail.

Post a comment.