The API vs DSL debate is an interesting one. IMHO, all good software is made up of layers, with each layer representing a domain. The outermost (application) domain might model a shipping company and hence any API/DSL at this layer should easily describe how to manipulate ships, cargos, routes etc. The innermost layer(s) might model web services or relational databases etc and so any API/DSL at these layers must model the low-level concepts that a developer would expect of these technologies. The key point is that at each layer the API/DSL should allow the user (be it, an application domain expert, or a hacker-geek dude!) to express the intent of what they want to do as easily as possible.
Now, my first guess is that if I was going to provide a DSL, I would probably only provide it at the application layer, and I would just create (hopefully) nice, clean APIs for the other layers (and of course, the DSL would really just be a thin wrapper around a nice clean application level API!)…
Of course, you could go DSL crazy and create one for each layer, although this seems like overkill to me, and brings up some pragmatic issues (which, actually apply even to a single DSL architecture):-
1) The ability of the user to learn a new language (even one targeted to the domain that they are in). This would obviously require the usual array of tutorials and reference manuals etc.
Currently when I code (I use TDD) I write tests in the same language as the shippable code. Obviously, every DSL can’t have extensions for testing, so would we use a low-level language or have a DSL for testing?