Summary

So, now we have a feel for DSLs and Groovy. We have seen how DSLs can be used in place of general-purpose languages to represent different parts of a system. We have also seen how adding DSLs to our applications can open up the development process to other stakeholders in the development process. We've also seen how, in extreme cases, the stakeholders themselves can even become co-developers of the system by using DSLs that let them represent their domain expertise in code.

We've seen how using a DSL that makes sense to a nontechnical audience means it can become a shared resource between programming staff and business stakeholders, representing parts of the system in a language that they all understand. So, we are beginning to understand the importance of usability when designing a DSL.

We have dipped a tentative toe in the water by looking at some Groovy code. We've gained an appreciation of how Groovy is a natural fit with the Java language due to its binary and class level compatibility. We have touched on the features of the Groovy language that make it unique from Java, and looked at how these unique features can be used as a basis for building on the base Groovy language with internal DSLs.

In the next chapter, we will go into more depth with the language itself and see how we can use these features to build programs. In subsequent chapters, we will dive deeper and see how the language can be exploited as an ideal platform for building DSLs on top of the Java platform.