Domain Modelling Pub

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

Quick example:

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

Important: domain topics must be tagged with DslDomain to get full functionality.

Associate inventories via annotations on each class:

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

no inventory registered
class::TestClass1 (
    someValue,
    ref:<>TestClass2,
    someValue,
    ref:<>TestClass2) ANNO(  inventory:String="diesel.db"="diesel.db",   inventory:String="diesel.db"="diesel.db")

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

no inventory registered
class::TestClass2 (    someValue,     someValue) ANNO(  inventory:String="diesel.db"="diesel.db",   inventory:String="diesel.db"="diesel.db")

Or by registering an inventory to a list of classes:

msg diesel.inv.register  (inventory="diesel.db"="diesel.db", connection="default"="default", classes="TestClass1"="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.

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)

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 .. 2021-03-27 | Tags: dsl , academy , reference


Viewed 110 times ( | Print ) this page.

You need to log in to post a comment!

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