Solution: What is the problem?
time to read 2 min | 361 words

I asked what is wrong with the following DSL:

specification @vacations:
    requires @scheduling_work
    requires @external_connections

I also constrained the problem so it can't be any of the following:

  • It has nothing to do with the implementation.
  • It has nothing to do with the actual engine running this.
  • Look for what isn't there.
  • It is only a problem when you scale up.
  • And no, there are no performance problems whatsoever.

The problem has nothing to do with technical issues, and all to do with management issues. The code above makes a certain modification to the current state of the system, but it doesn't tell us why!

Consider the case where we have several hundreds (or thousands) of those rules.  How are you going to associate the end result of executing all those rules with the actual rule that caused a particular issue? How are you going to know why?

For a well defined DSL, we need more than just the syntax, we need an environment that supports the whole development process, and that includes being able to give good answers during runtime, about what caused what and why. Some of that are things that you can add to the syntax, that is, you can write is as:

specification @vacations: 
	requires @scheduling_work, "Vacations requires work scheduling so we can plan around vacations"
	requires @external_connections, "We need to order vacation spots"

Note: I don't want to hear about the ridiculousness of the business example, I know it is. It is here as an example for something else, not the actual business logic.

But this still doesn't give you enough information, the DSL engine itself needs to record the information about what rule (and what script) had modified the state of the application, and allow you to just directly from the result to the rule that allowed it.

Otherwise, what you have is chaos.

Tweet Share Share 0 comments
Tags: