Due to a Hilarious Library Mishap, I have a huge stack of tech books on my desk at work. (Don't ask, it's a really long story of libraries not understanding technology.) The most interesting-looking of the stack, Domain-Specific Languages, I took home to read. It is heavy. (Which is why I asked the library for digital versions, and ... let's not get into that just now.)
I read the background section, about 150 pages, and the first few patterns/recipes. I get two conflicting impressions. first, DSLs is "Compilers for Mice". The background is a simplified, no-theory overview of compiler technology. Fowler over-simplifies the concepts so that they are 80% correct and all have non-standard names. In some cases he doesn't appear to understand the underlying theory himself. You could get some use out of this section, but you're better off reading the Dragon Book even though it's Real Hard.
The second impression is that DSLs is the "Compiler Cookbook". It's a list of things you will end up writing into your compiler if you are writing a Serious Compiler. So you might as well learn about them and use them for your Compiler-Lite as well. A lot of them are special cases of things that are explicit in the functional world, like the Writer monad or the State monad, and they have Special OO/DSL names like Notification or Context. But whatever. Still useful for first-timers.
Fowler retains his annoyingly myopic view of the computer language world as "Java". Every time he makes a statement about how rare, common or useful a language feature is, append "in Java" to that sentence. The most egregious statement is about how rare closures are. Most of the languages in use today have closures except C and Java. That's pretty common!
He also explicitly mentions that he knows little about functional programming. Missing functional programming per se isn't a big loss for this book, but functional languages attract a lot of the people working on language, so he misses or misunderstands some of the language techniques and culture that emit from there. For example, he muses at the end of one chapter something like "if only there were a book that explores alternative models of programming" (where alternative means non-imperative).
In conclusion, I have worked with this stuff way too long to remember what a newbie needs to learn. I am biased. From an expert perspective, though, there's an awful lot of the baby-talk and beneficient lying that accompanies mediocre teaching.