Domain Entities

First, an example of a configurable mug:

Mug:
    meta:
        title: Awesome Custom Mug

    label: string
    has_handle: bool
    color:
        type: choice
        constraint: one
        options:
            - Black
            - Sepia
            - White
    height:
        type: numeric
        min: 50
        max: 150
        step: 1
    diameter:
        type: numeric
        min: 80
        max: 100
        step: 1

Fields

The domain entity structure is designed to be rather straight forward. In the example above the Mug can have any number of fields, each with a corresponding Data Type.

Field names can be pretty much anything, but a few restrictions apply:

  • Field names should not contain any whitespace characters
  • meta is a reserved keyword and cannot be used as a field name

In the example above each field in the Domain Entity must declare a type. While some types can be declared with a shorthand notation (e.g. bool) others have parameters that you can specify to constrain the input or enable other features.

A field with a bool type could just as well be declared like this:

has_handle:
    type: bool

Since the boolean type has no other parameters the short notation is more efficient.

Field structure

As you probably could already guess all field declarations share an underlying structure:

field_name:
    type: <type name>
    constraint: <optional|one|0..1|0..n>
    type_specific_parameter1: ...
    type_specific_parameter2: ...
    # etc

The type parameter is required, everything else is usually optional (i.e. with a sane default value) unless it is required by the specific type.

Metadata

Besides fields each entity can also contain a metadata block (meta). Metadata is mainly there to support user-defined behaviors and is not processed by Konfoo.

The one exception to that is title - this is used in various places when Konfoo needs to display a name for the domain entity in a user-friendly way.

Composition

The domain definition file can contain any number of different domain entities. Of course for them to be useful they need to be referenced by other entities.

To demonstrate such a system consider a very primitive shopping cart:

root: Cart

Cart:
    products:
        type: list
        model: Mug

Mug:
    color:
        type: choice
        constraint: one
        options:
            - Black
            - Sepia
            - White