Prior to the 2.0 release of Sclable’s Business Application Development Platform, the Domain Designer was part of the generic application and vice versa. As of Platform 2.0 the Domain Designer is not only a standalone application, but also a good showcase of what can be achieved upon Sclable besides extending the generic application.

Extensibility through packages

Sclable’s Domain Designer is a complete re-write and re-design. It is available as a package from the Sclable Factory, our centralized package hub, and can be installed via BOB, our build tool. The Domain Designer allows you to access any of your local or remote Sclable installations via a web service, which is a package of its own. Both packages serve as a good example of how functionality can be packetized when extending Sclable.

Model, visualize and explain complexity

Sclable’s Domain Designer is developed with large and complex business domains in mind. On the one hand we want the tool to let you be quicker than copy and paste. On the other hand it should be as useful for you as a developer when you need to visualize and explain the complexity of a business domain to others.

In-Graph Editing

Since ERD and Workflow graphs are used a lot when modelling business domains, we decided to drop server side rendering with GraphViz in favour of client side rendering with dagre/dagreD3, so you can watch the graphs morph while modifying the domain model. This helps a lot to stay focused, especially when you are editing large graphs, giving the tool a generally more responsive feeling.

Sclable workflow graph. This image shows a workflow from our sample package featuring a ticketing process. The example shows a highlighted action named “set to solved” which is a workflow action of the type “edit”. It lets you set tickets to the state “solved” regardless of their pre-state. This is especially useful for interactive data cleaning after deleting a state when instances of the entity referencing the state get decoupled. Image: "Sclable.com"

Sclable workflow graph. This image shows a workflow from our sample package featuring a ticketing process. The example shows a highlighted action named “set to solved” which is a workflow action of the type “edit”. It lets you set tickets to the state “solved” regardless of their pre-state. This is especially useful for interactive data cleaning after deleting a state when instances of the entity referencing the state get decoupled.
Image: “Sclable.com”

Workflow Edit Action

Actions of type “edit” can have a post-state while not having a pre-state. This allows instances to be set into a specific state from any state. An example use case for this feature is a “cancelled” state within a order workflow for example, when you want an order to be able to be cancelled anytime.

Editing Action Attributes. This image shows how action attributes can be defined as of Sclable 2.0. From ‘invisible’ over ‘read only’, ‘editable’ and ‘required’ different levels of user access to an attribute’s value can be set. What’s happening behind that is quite a complex combination of modelling actions: setting ‘invisible’ in fact deletes an action attribute from the sclable core domain, ‘visible’ adds the action attribute with a boolean flag for ‘readonly’ set to true, ‘editable’ sets the ‘readonly’ boolen to false and ‘required’ creates a corresponding restriction along with the action attribute. Image: "Sclable.com"

Editing Action Attributes. This image shows how action attributes can be defined as of Sclable 2.0. From ‘invisible’ over ‘read only’, ‘editable’ and ‘required’ different levels of user access to an attribute’s value can be set. What’s happening behind that is quite a complex combination of modelling actions: setting ‘invisible’ in fact deletes an action attribute from the sclable core domain, ‘visible’ adds the action attribute with a boolean flag for ‘readonly’ set to true, ‘editable’ sets the ‘readonly’ boolen to false and ‘required’ creates a corresponding restriction along with the action attribute.
Image: “Sclable.com”

Workflow Action Attributes

Attributes can be assigned to an action within a workflow with an additional “read only” attribute. This allows you to specify accessibility levels: invisible (attribute is not an action attribute) to visible (attribute is an action attribute but set to “read only”), editable and required.

Reference Types

These can be edited via the all new relation editor from within the entity view. Reference types become important for the definition of migration paths, where the domain designing developer defines how relational migration issues should be resolved upon deletion of an instance.

Sclable Domain Designer: entity editor tabs. This image shows the workflow-, attribute-, relation- and agenda editor tabs of the entity editor. The ? key will show a context sensitive hot keys cheat sheet, alt+h displays inline hot keys as seen in the screenshot. Our goal with hot key support is to allow for domain modelling without using a mouse. Image: "Sclable.com"

Sclable Domain Designer: entity editor tabs.
This image shows the workflow-, attribute-, relation- and agenda editor tabs of the entity editor. The ? key will show a context sensitive hot keys cheat sheet, alt+h displays inline hot keys as seen in the screenshot. Our goal with hot key support is to allow for domain modelling without using a mouse.
Image: “Sclable.com”

Hot Keys

The ? key will bring up a hot key cheat sheet, alt+h will display contextual hotkeys inline. Domain modelling now can be done from the keyboard without using a mouse. We will subsequently extend the set available hotkeys to in-graph editing and navigation as well.

Upcoming Features for 2.1

Subsequently we will add every Sclable Core Engine Feature to the Domain Designer. Depending on the complexity of the functionality itself it might take one minor release’s time for a core feature to be fully implemented by the Domain Designer. For the 2.1 release we plan to implement the Agenda/Action Binding Editor and the Selection Editor.