Domain Modelling Pub

Diesel has expressive domain modelling functionality. You can model a domain and then manage the domain's objects in several ways:

  • define wiki categories
  • DSL modelling as below
  • importing external domain models from domain adapters

Quick example, defining a class with DSL modelling:

Define a class:
$anno (table="TestClass1")
$anno (inventory="diesel.db.memshared")
$class TestClass1 (someValue:String, ref:<>TestClass2)

Important: domain topics must be tagged with domain to get full functionality, otherwise they are not automatically parsed and understood. Diesel will automatically load and add to the current domain and topics tagged domain and rebuild the entire domain when any domain topic is edited.

Associate inventories via annotations on each class:

anno  (  inventory="diesel.db.memshared"="diesel.db...)

listAll | new
class TestClass1 (
) ANNO(  inventory:String="diesel.db.memshared"="diesel.db.memshared",   inventory:String="diesel.db.memshared"="diesel.db.memshared")

anno  (  inventory="diesel.db.memshared"="diesel.db...)

listAll | new
class TestClass2 (  someValue,   someValue) ANNO(  inventory:String="diesel.db.memshared"="diesel.db.memshared",   inventory:String="diesel.db.memshared"="diesel.db.memshared")

Or by registering an inventory to a list of classes:

msg diesel.inv.register  (inventory="diesel.db.memshared", connection="default", classes="TestClass1")

This second option is trickier: the association is only available after running this message, so if you don't put it in the EnvironmentSettings for diesel.realm.configure it won't be available by default...


  • the table annotation is optional, the default will use the class name as the table name

Modelling a domain

You can define domain elements in either special topics called Category or as DSL in one tagged with either of Category, domain, DslDomain. You can also define a domain on the fly within rules specifications (specs) and also import a domain definition from an external representation (for instance importing an ODATA domain from a Microsoft Dynamics instance. These types all work together and are merged into one domain per project and per diesel flow.

For instance, you can define a class in a few separate topics and the definitions are merged into one, making it easy to extend and annotate concepts.

Modelling a domain in Wiki

See Wiki Domain Guide and Wiki Category Guide.

TODO elaborate

Modelling a domain in DSL

You can also model classes and other domain elements in DSL.

The main domain modelling constructs are:

  • $class concept or class or type
  • attribute/parameter
  • $assoc associations
  • $anno annotations - can add properties to classes or other domain elements
  • $def functions, actions, $msg messages
  • formats, viewers etc
$class Class1 [T] (attribute1, attribute2:String, ref:Class2)

Some of the things you can do are:

use interpolation in attribute names

$class Class1 ('${expr}')

use default values

$class Class1 (name, timestamp = now())
$val c = new Class1 {name="jake"}

annotate with display annotations

$anno ( ui.fieldsToShow = "-name,schedId,cronExpr,timeExpr,-category")
$class Class1 (...)

Annotations are:

  • ui.fieldsToShow which fields to show in lists, use dash to remove defaults

annotate attributes

$class Class1 (
  @key name, 
  @excache timestamp

Annottions are:

  • key to mark unique id / primary key for persistence
  • excache to mark recalculatable attr in display

Domain scope

Each realm has an associated domain, containing the categories defined as wikis as well as any domain modelling defined in topics tagged with DslDomain or topics in the DslDomain category.

Each flow extends that default realm domain with any domain modelling elements defined in it's own specifications, over and above those already captured in topics tagged domain.

The default realm domain can be browsed, but not the individual flow domains and entities - remember that! The diesel browser may sometimes be able to figure out the context of the entities you want to browse, but in general you're better to define the classes and domain relationships in a domain topic, so it's known to the entire realm.

TODO You can also manually add to the main domain specific elements, by name - only from your [[EnvironmentSettings]], on startup, on the [[msg:diesel.realm.configure]].

$send diesel.dom.add(classes="TestClass1")

Note that diesel.dom.add is a "todo" so not available yet.

So, when browsing a domain and you see a message like nothing found about TestClassInv1a double check if TestClassInv1a was supposed to be included in the realm's default domain and if it is actually included...

Was this useful?    

By: Razie | 2020-10-17 .. 2022-11-15 | Tags: dsl , academy , reference , domain

Viewed 561 times ( | History | Print ) this page.

You need to log in to post a comment!

© Copyright DieselApps, 2012-2024, all rights reserved.