Data modelling - the basics

Learn about the platform’s three types of ranked data: aggregates, entities, and enumeration. Then, discover how to add them to a data model and create standard fields while building a CRM. Commands and their params will also be made to add functionality to the application.

An Aggregate consists of a grouping of elements that share a key concept. Our data model for our CRM contains, among other things, an “account” and a “user” aggregate. In our « Account » aggregate, you can find the entity « Contact ». An Entity is like an aggregate, except for grouping elements inside a critical concept and belonging to a collection—namely, a list of contacts under an account. The field « Language » comprises a static list of defined values in which a user selects one entry. This is what we call an Enum.

Before going any further, look at this UML diagram representing the data model for the CRM application used for this Getting Started documentation.

At this stage, we will create the Account aggregate, the Industry enum, a Contact Entity, an account list page and detail page, and some standard fields.

Create an aggregate and its fields.

First, open the DAZZM no-code platform by clicking once on the page, then pressing F2 or Function + F2 on a keyboard.

The default application template contains a User aggregate. It’s a mandatory aggregate that helps the system run smoothly. It’s expected that it will need to be enhanced as the application grows.

To add an Aggregate to the application’s data model, right-click the “Type” folder and select the “Add aggregate” option. For our example, type in “Account” in Name and save.

Create standard fields for accounts by opening its aggregate and right-clicking on the “fields” folder. Of the two options proposed, select “add field.” In this example, the name of the field is “name,” and the type is “text (string).” This type is best for single-line text box.

The system automatically generates an ID field under each new aggregate and entity. This allows, for example, DAZZM to assign unique IDs automatically for each new account.

Next, create a “isVIP” standard field and select the type “Yes/No (Boolean).” Add another one for “accountNumber”, with “number” as type. The “number” type restricts users to numeric values and the symbols plus and minus. It’s often used for phone or account numbers.

Another type option when creating a new field is referring to a different aggregate than the one where the new field is. The field creation process remains the same as seen previously. For our example, we are creating “accountManager,” which is part of the Account aggregate and of type “user.” When picking an account manager for an account, it will generate a drop-down list of all users. Eventually, the list of users could be refined. This will be covered later in the learning process.

To follow our CRM example, also create a “phoneNumber” and “website” fields.

Create commands and set their parameters

When you right-click on the Commands folder under an aggregate, you have four options: add update command, add create command, add delete command and add entity create command. Each option will use a wizard to simplify the process of adding parameters.

Let’s go through the steps of adding a create command.

After the wizard opens, enter a more specific name for the command, then, on the wizard’s second step, add your params. Params are the fields that will be displayed when the user triggers that command. Using drag and drop, rearrange the order of the params more logically, as the order in which they are listed here will be identical for the user. Then, set which fields will be required. If you need to add additional fields to the command’s param list after the wizard has been closed, right-click on the params folder under the command and select “add parameter”. From the parameter folder of a command, you can also use drag and drop to change the order of the fields.

It's good to know that every field not required in the command’s dialogue window will have the option to be cleared by the user.

For our “createAccount” example, add “name,” “accountNumber,” “isVIP,” and “phoneNumber.” Set “name” and “phoneNumber” as the two only required fields and click Done.

The update command process is very similar to the create command one. The only difference is that the wizard allows the user to enter a label for the command. For the “editAccount” command, add all fields to the params list and put “name,” “isVIP,” and “phoneNumber” as required.

Remember that the parameter folder should group fields the user might need to edit simultaneously. Those fields should be grouped in the application's UI for apparent reasons.

Create an Enum

In the context of this CRM, each account will be associated with one industry type. The industry list is an enum. To add it to the data model, start with a right-click on “fields” under the Account aggregate and select “add field.” In the “name” section, because this enum won’t be a collection, write “industry” using its singular form.

When creating an enum, ask yourself if the user might have to select multiple options in that list. If the answer is yes, check “is collection” and ensure that the dialogue's first “name” field uses the plural form.

After selecting “new enum” as “type,” 2 more fields become available. These are the enum’s name and label. This name should always use a singular form and start with a capital letter, as it represents what each item in the list is.

To add values under the enum, open the field, right-click on the enum “Industry,” and select “add value.” They should be written in all caps and words should be separated by an underscore. This should be automatically done for you as you type in your label.

After adding all necessary values to the industry enum, add it to the params for both the “createAccount” command and the “editAccount” one. As explained previously, to add a param to an existing command, open it, right-click on the parameter folder and select “add parameter”.

Of course, as a solution dev, it is up to you to decide if the field is best integrated to an existing command or create a stand-alone update command for the field. In this scenario, let’s create one for the “accountManager” field. After completing a stand-alone command for “modifyAccountManager, ensure that the field is not part of another update command. In our case, we need to remove the field from the parameter folder of the “editAccount” command.