Domain Modelling Pub   Share

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)

Associate inventories via annotations on each class:

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

$anno (inventory="diesel.db.memshared")
$class TestClass2 (someValue:String)

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...

NOTES:

• 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.

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.

$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...

You need to log in to post a comment!