A Domain IDE is an integrated development environment for domain experts rather than general-purpose programmers. It lets them author business knowledge as precise domain-specific language (DSL) content, so that content can serve as a specification for a business-centric software system called the Runtime. Developers build the IDE and the parts of the Runtime that the DSL cannot specify; domain experts maintain the knowledge that can be expressed in the DSL. section 1.2 section 1.5
The central experience is a DSL editor designed around domain concepts, not character-by-character text entry. A projectional, or structured, editor renders the underlying DSL data as an appropriate UI and permits only meaningful structured edits. Styling, choices, and guided editing make rules readable while helping users create valid content; constraints can flag content that would cause failures in code generation or the Runtime. section 1.2.1 section 1.2.2 section 1.4.4
Figure 1.14 The architecture of the Domain IDE
This architecture view locates the Domain IDE between domain experts, stored DSL content, and the generated Runtime. section 1.2.2
A Domain IDE combines a domain-focused authoring surface with a delivery workflow:
- A browser frontend displays DSL content and provides the projectional editor through which domain experts manipulate it. section 1.2.2
- A backend API and repository store and retrieve the business knowledge represented as DSL content. section 1.2.2
- A build system feeds stored content to a code generator, combines generated code with manually written code and configuration, and builds the Runtime. section 1.2.2 section 8.0
- Builds can be triggered from the IDE, a command line, or continuous integration. section 1.2.2
Car-rental pricing rules
A domain expert can maintain rules such as applying discounts when a rental date range contains a Saturday or starts in December. Instead of typing unrestricted prose, the expert selects valid constructs and values in the editor. The resulting DSL content captures pricing knowledge precisely enough to generate the Runtime behavior, while invalid combinations can be highlighted with an explanatory error. section 1.2.1 section 1.4.4 section 8.0
This arrangement shifts a substantial portion of software development from manually translating documents into code toward domain experts maintaining executable specifications. It can make changes faster and reduce communication gaps because the DSL becomes a shared language between domain experts and developers. It also carries costs: developers must understand the domain and implement the IDE, while experts must clarify the domain sufficiently for the DSL design. section 1.3.1 section 1.3.4
A Domain IDE must also support changing content over time. Collaboration may be synchronous through real-time editing or asynchronous through distributed version control. Projectional editing can represent edits as small AST deltas, and versioned DSL content can be checked and migrated when the IDE and content versions differ. section 10.0 section 10.4
