Domain

Before you Start

🔥 This feature is currently considered experimental. Try it out and give feedback by reporting bugs and suggesting new features. It’s not recommended for production use.

🛠️ This feature is available to studio makers.

This page describes the Domain editor available to studio makers in Sirius Web. Use it to understand the concepts behind the editor before following the step-by-step tutorial.

1. Introduction

The Domain editor lets you define business concepts (entities, attributes, relations) directly inside Sirius Web. Everything happens inside the browser—there is no code generation step, no external Eclipse install, and the resulting domain is immediately usable by the View editor and by end users who create instances. The editor targets tree-structured models (each element has at most one container), which map naturally to explorer trees, forms, and diagrams.

2. Core concepts

  • Domain package – top-level container that groups entities belonging to the same DSL.

  • Entity – equivalent to a class in UML; it can declare attributes and relations.

  • Attribute – scalar value (string, integer, boolean, enum).

  • Relation – reference toward another entity; can be containment or cross-reference.

  • Cardinality – each attribute or relation can be mandatory/optional and single/multi-valued.

Every domain you provide is stored as structured data (serializable to JSON) so you can version it in Git, review it, or reuse it across workspaces.

3. Authoring workflow

At a high level the domain follows these steps:

  1. Create or open a studio project dedicated to your DSL.

  2. Add a domain package and populate it with your main entities.

  3. Configure attributes and relations on each entity.

  4. Iterate quickly by reopening your test projects so that Sirius Web reloads the latest domain.

For a detailed, click-by-click tutorial see Create your first domain.

4. Testing and deployment

  • The domain is live inside your running environment—no build step is required.

  • When ready, package the studio project (domain + views) and deploy it along with the application, or export/import it into another workspace.

  • Because the domain is a model, you can analyze it with EMF Compare, enrich it with M2Doc documentation, or store it in source control like any .odesign replacement.

5. Practical guidelines

  • Name entities using business vocabulary so end users immediately recognize them.

  • Keep inheritance shallow; use composition (relations) whenever possible to avoid brittle hierarchies.

  • Model enumerations for any attribute with a limited set of values—this enables select widgets automatically in later views.

  • Before handing the domain to colleagues, build a “sample” project that showcases valid instances; it doubles as regression data when the domain evolves.