You are an architect on your company's new flagship application. The app encompasses several business and technical domains that are, in your opinion, well suited to domain-specific languages (DSL). In years past, you would have turned to XML as the solution for all your DSL needs. With or without schemas, you would specify configuration files and scripts in files foul with angle brackets. Thankfully, for the discerning .NET architect, DSL implementation options are now plentiful.

For each DSL you create, you need to identify the target user for that DSL. Is she a non-developer subject matter expert, a particular kind of developer, or an end user? This choice will drive the kinds of tools you make available to support the DSL. It will also influence choices such as whether your DSL is interpreted or when it is compiled.

Before selecting DSL implementation strategies or tools, you need to decide the application layer in which each DSL will live. Some are intended to support run-time configuration and initialization. Others may be part of well-defined and reasonably confined components. Still other DSLs might be used to script together your application at the macro scenario level. Even particular idiomatic coding styles are essentially DSLs. Martin Fowler calls these "internal DSLs." These choices influence other architectural decisions. We'll begin our examination of the implication of some of these decisions with a brief description of DSLs in general. Then we'll look at different techniques for including DSLs in a larger architecture.

DSLs have several advantages over general-purpose programming languages (GPLs). DSLs directly support high-level concepts from the business domain with program constructs (services, classes, interfaces, and libraries, whatever is appropriate to the target technology and the business requirement). The language takes responsibility for transforming, compiling, or interpreting those business concepts into a working system. When the business domain and technology expertise are encapsulated in a DSL, users of the language boost productivity while also improving quality.

It's useful to point out that the boundaries between GPLs and DSLs are fuzzy, if they exist at all. For example, C was originally created for the purpose of system programming. Perl was originally created for text processing (which is still its best domain). Java was an environment meant for set top boxes and then Web applications. Lisp was originally created for AI research. Now it's used in an operating system masquerading as a text editor. Even COBOL and Fortran are DSLs, although not Business DSLs (BDSLs). Many people say DSL when they mean BDSL, where business is used in the same sense as business logic. For purposes of this article, I would like to include business domain and non-business DSLs. In many IT shops, the non-business DSLs outnumber the BDSLs.

Whether business-specific or not, each DSL should provide the ability to say useful things over a well-defined domain. This implies the ability to describe a domain and the ability to specify the grammar and semantics of statements or expressions ranging over the selected domain. A BDSL should be created only where an organization has a clearly defined domain with well-understood semantics, and then it should mimic the normal forms of communication used when discussing the domain. From an architectural perspective, what we're really thinking about is providing points in an application architecture where domain concepts are expressed in more natural forms.

When it comes to including DSLs in an architecture, how you implement a DSL and where it fits in your architecture are closely related. There are many approaches to implementing DSLs, from literate (sometimes called intentional, although there are other meanings for intentional) programming to fully compiled custom languages. We'll start with the most prominent DSL creation tool in the .NET sphere and work down toward simple code-style implementations.

A typical enterprise component architecture like the one shown in Figure 1 presents many opportunities for serving domain expert users with DSLs. Any one of the components might include a DSL for configura-tion purposes or as part of its public interface. In addition, a DSL could be used to wire together or orchestrate interactions between multiple components in a single module or subsystem.

In September, Microsoft released another CTP of the Domain-Specific Language Tools (http://lab.msdn.microsoft.com/teamsystem/workshop/dsltools/default.aspx). The final release of the DSL Tools, planned to come on the heels of the Visual Studio 2005 RTM, will provide everything necessary to create visual domain language editors that can be used to generate code or for other DSL-related purposes. Microsoft provides tutorials for the current DSL Tools release. I won't rehash them here. The key to understanding the role Microsoft's DSL Tools play in architecture is that they give you the ability to create graphical editors for DSLs. The graphical notation maps to some other form, most commonly a textual representation. In this sense, the DSL Tools can be applied in the exact same way as textual DSLs.

One approach to including DSLs in an architecture is to use modular design to encapsulate DSLs in specific pieces of an application. A component or module might be configured by or execute logic provided by a DSL. Common examples of DSLs of this type are template engines, database access layers (using SQL as a language), and rules engines. In this approach, the DSL is part of the public API of the component. DSLs used in this fashion are often formally defined or documented textual languages. This is the approach commonly described for external DSLs. The architectural challenges are relatively simple in this case. Each DSL is implemented in a well-defined component.

The example in Figure 1 includes a business rules engine that interprets business rules defined in a visual or graphical DSL. The Data Adapter's interface gives dependent components the ability to provide SQL for specific operations not supported by the underlying mapping technology.

Finally, the Template Engine uses templates stored in the file system. The templates may be defined using XML, a graphical editor, or some other notation. The purpose for using DSLs in each of these components is to provide a more natural or efficient expression of logic in the domains - in this case business rules, data access, and templates - than is provided by a GPL like C# or VB.Net.

When providing documentation for a component that uses one or more DSLs, it is good practice to provide, along with standard interface documentation, a guide to the DSLs supported with several nontrivial examples. DSLs may provide a better way of communicating or capturing ideas in particular domains, but they can add to the surface area and complexity of components. It's important to weigh the benefits of creating and implementing a DSL against any additional learning curve that comes with it. Microsoft's DSL Tools will make language construction more accessible for application developers, but they won't eliminate the need to properly document DSLs.

There are other approaches to DSLs that involve using the internal capabilities of a language or platform to support a DSL-like experience for developers. UML provides one way to define an internal DSL. A domain model such as the one shown in Figure 2 describes a business domain in a formal notation. The domain class diagram captures part of one possible description of the business domain of libraries. For space reasons, it includes only those elements that are critical to the examples. The approach to the domain model class diagram in Figure 2 is based on color modeling (see the first entry in the References section). As with the other topics addressed in this article, there are several good choices when it comes to approaches to domain modeling (see second and third entries). As you will see from the references, the topic of domain modeling has been around for a long time. Microsoft's DSL Tools, Model Driven Architecture (MDA) solutions such as Borland's Together Architect 2006, and the emergence of what Martin Fowler has called "language workbenches" are generating new interest in domain modeling and DSLs (see the fourth entry).