Domain Context

Last updated 1 day ago

A Domain Context is an instance of an ontology, applied to your project. It is the working unit, and where most of your time in Fusion is spent.

Creating one

Create a Domain Context from its project, give it a name and a description, then open Contents and upload the material it should be built from.

The documents are what the model is generated from. The name and description situate the domain; the contents supply its substance. The more material you give it, the sharper the model.

Anything that explains the product counts. A specification, a backlog export, an architecture diagram, the recording of a design review. Mix them: each kind of document fills in a different side of the model.

Context Objects

A Domain Context is made of context objects. Each one is the meeting point between a business concept and the code that implements it, through its Code Parcel.

Type places an object in the model. Core is the root of the domain. Functionality is what the product does.

Rule and Children rule are what make this a feature model rather than an outline:

FieldWhat it controls
Rule	Whether this element is mandatory or optional in the domain
Children rule	How its children combine, for example `All (And)`

Relations in the graph are labeled accordingly, so reading the model tells you not only what exists but what is required, what is optional, and what combines with what. The same model can describe several variants of a product rather than one fixed shape.

Each object also carries a name, a description and a color, editable from the Properties tab of its detail panel.

Graph view

Your domain, as a map. See its shape and its dependencies at a glance.

Click a node to open its detail panel
Zoom between overview and detail
Use the funnel filter to isolate a functional sub area
Add Object Context or Subflow to extend the model, with undo and redo
Select a node for Add node, Duplicate and Delete

Reading connector data on the model

This is where the model stops being a diagram. The lightning icon on the left opens Service Connections, and from there you decide what your connected tools display on top of your domain.

Each connector has a toggle, so you can show one at a time or several together. Under a connector, pick the measure to project onto the graph: for SonarQube that means Bugs, Code Smells, Vulnerabilities, Security, Reliability, Maintainability, Technical Debt, Number of Lines or Code Coverage. Hide statistics clears the overlay.

Nodes then carry a severity label, CRITICAL or MAJOR, and counts broken down by severity. You are looking at your product, not a file tree, and the parts in trouble are the ones that light up.

Each connector also shows its scheduler, Default scheduler (UTC), with controls to run it now and to see its history.

The Data panel

Click the panel icon on a node to open Data: everything your connected tools know about that part of the domain, grouped by connector and by category.

SONARQUBE  RELIABILITY       189 | 113  Code Smells                     13 |   7  Bugs  MAINTAINABILITY    39 | 87 | 79 | 45  Code SmellsAIKIDO                      3 | 14 | 61  SAST

The pin button keeps the panel open while you move around the graph, which is what you want when comparing two areas.

The point is the aggregation. SonarQube reports code smells and bugs, Aikido reports security findings, and neither knows what a feature is. Here both are read against the same business concept.

Table view

The same model as a list, with the measured columns the graph cannot show: Files, Lines of code and Data item per context object. Built for bulk editing and methodical review.

Lines of code per functionality is the column that tends to surprise people. It is the first real answer to how much of a codebase a feature represents. On a real project, one feature carrying 287 files and 32,000 lines next to another with 3 files and 191 tells you where the weight sits before anyone opens an editor.

Data item counts what connectors report for that element, and reads No connector data available when nothing is attached. It is the quickest way to see which parts of your model are covered and which are blind spots.

Selecting a row opens the detail panel on the right, with two tabs. Data shows connector findings for that element. Properties holds its name, description, type, color, and its Rule and Children rule.

The material the model is built from: specifications, diagrams, data, recordings, knowledge assets. Mobioos analyzes them and builds the Domain Context from them.

Open Contents from the toolbar, then drop files or browse. Upload up to 20 files at a time, 100 MB each, and add more whenever the product moves.

Members

Invite people to collaborate on a Domain Context with + Invite Member. Membership exists at two levels, the organization and the Domain Context, so access can follow a functional area rather than the whole organization. See Organizations and projects for teams and roles.

Share copies a link to the Domain Context, so you can hand it to someone who already has access.

Versions

Versions are how you track a Domain Context over time. Create version captures the current state so you can refer back to it. MAIN is the working state, and everything you edit happens there.

Your product moves, and its model moves with it. A version lets you say exactly what the model looked like at a given point, and Statistics can be read against MAIN or against your versions to see what changed in between.

Configuration

The gear icon opens Domain Context Configuration: General for name and description, Contents, and Context status.

The Danger Zone holds Delete Domain Context. You type the name of the context to confirm. Deletion is permanent and removes everything it contains.

A project cannot be deleted while it still holds Domain Contexts, so contexts go first.

Forge plugin settings

The puzzle icon opens the Forge configuration as read only. Settings are inherited from the project and can only be created or changed in the Forge VSIX extension. See Forge.