Graph Analysis

Graph Analysis: Impact Assessment & Architecture Evaluation

Use this skill when assessing the impact of a change, identifying risky elements, evaluating module health, or planning a structural refactor. The graph tables model the entire project as a dependency graph and expose topology metrics on top of it.

When to Read This Skill

• Before modifying an entity or microflow that might be widely used
• Before moving elements between modules
• When assessing architectural health (coupling, cohesion, god nodes)
• When planning to split a module or extract a bounded context
• When identifying dead code to remove

Setup: Two-Step Refresh

Two separate commands are needed. The full catalog must exist before community detection runs.

# Step 1: Build the full catalog (activities, widgets, cross-references)
# Skip if already fresh — check .mxcli/catalog.db mtime
./mxcli -p app.mpr -c "REFRESH CATALOG FULL"

# Step 2: Run graph algorithms (community detection, centrality, layers, cycles)
./mxcli -p app.mpr -c "REFRESH CATALOG COMMUNITIES"

What each step populates:

An empty table from the second row is ambiguous unless you check. Step 2 is not a build mode — it augments whatever the catalog is, so Build mode: full says nothing about whether it ran, and before mendixlabs/mxcli#1060 an un-run pass and a genuinely cycle-free project produced the same 0 rows. A query now warns requires refresh catalog communities (not run for this catalog) when the pass is missing, and SHOW CATALOG STATUS has a Graph analysis: line. No warning plus no rows is a real answer; treat anything else as "not computed yet", not as "clean".

REFRESH CATALOG COMMUNITIES with a resolution modifier:

• REFRESH CATALOG COMMUNITIES — default resolution (balanced granularity)
• REFRESH CATALOG COMMUNITIES resolution 0.6 — coarser clusters (fewer, larger communities; good for monolith-to-multi-app planning)
• REFRESH CATALOG COMMUNITIES resolution 2.0 — finer clusters (more, smaller communities; good for identifying sub-modules within a large module)

Use Case 1: Pre-Change Impact Assessment

Run before modifying any entity, microflow, or association. Takes under a minute.

-- Is this element a god node? How many things depend on it?
SELECT Asset, ObjectType, InDegree, OutDegree, Degree
FROM CATALOG.GRAPH_GOD_NODES
WHERE Asset = 'MyModule.MyEntity';

-- What layer is it in? (0 = leaf/data, higher = orchestration)
SELECT AssetName, Layer
FROM CATALOG.GRAPH_LAYERS
WHERE AssetName = 'MyModule.MyMicroflow';

-- Is it a bridge? Would breaking it disconnect subsystems?
SELECT AssetName, PageRank, Betweenness
FROM CATALOG.GRAPH_CENTRALITY
WHERE AssetName = 'MyModule.MyMicroflow';

-- Which community does it belong to? What else is in that cluster?
SELECT c.AssetName, c.CommunityId, cs.Label
FROM CATALOG.COMMUNITIES c
JOIN CATALOG.COMMUNITY_SUMMARY cs ON c.CommunityId = cs.CommunityId
WHERE c.AssetName = 'MyModule.MyEntity';

Interpretation:

• InDegree > 15: many callers — changing this will require wide testing
• Betweenness > 100: this element is a bridge; removing or changing its signature will disconnect subsystems
• High layer number (8+): orchestration-level code; changes propagate downward
• Layer 0: pure data entity or leaf microflow — changes affect only direct callers

Use Case 2: Dead Code Identification

-- All unreferenced elements project-wide
SELECT QualifiedName, ObjectType, ModuleName
FROM CATALOG.GRAPH_DEAD_ASSETS
WHERE NOT (ModuleName IN ('System', 'Atlas_Core', 'Atlas_Web_Content',
    'Atlas_NativeMobile_Content', 'WorkflowCommons', 'CommunityCommons',
    'NanoflowCommons', 'NativeMobileResources', 'WebActions', 'DataWidgets'))
ORDER BY ModuleName, ObjectType;

False positives to exclude before deleting:

Safe to delete: pages, snippets, and microflows with no inbound edges that do not match any of the patterns above, and that are not referenced in navigation (check LIST NAVIGATION).

Use Case 3: Module Health (Cohesion & Coupling)

-- Cohesion per module: low % = module does too many things / should be split
SELECT ModuleName, IntraEdges, InterEdges, CohesionPct
FROM CATALOG.GRAPH_MODULE_COHESION
ORDER BY CohesionPct ASC;

-- Cross-module coupling: find unexpected entanglements
-- Filter to custom modules by replacing the IN list
SELECT SourceModule, TargetModule, Edges, RefKinds
FROM CATALOG.GRAPH_MODULE_COUPLING
WHERE SourceModule IN ('MyModule1', 'MyModule2', 'MyModule3')
  AND TargetModule IN ('MyModule1', 'MyModule2', 'MyModule3')
ORDER BY Edges DESC;

-- Dependency direction breakdown: what kinds of references cross module boundaries?
SELECT SourceModule, TargetModule, RefKind, Edges
FROM CATALOG.GRAPH_MODULE_DEPENDENCIES
WHERE SourceModule = 'MyModule'
ORDER BY Edges DESC;

Interpreting CohesionPct:

Coupling RefKinds to watch:

• retrieve, datasource, create, change: data access across module boundaries — should go through a service microflow in the owning module
• call: microflow calls across modules — acceptable if intentional API
• generalize: entity inheritance across modules — hard to refactor, flag as a blocker for splits
• layout: purely structural, always acceptable

Use Case 4: Community Analysis (Bounded Context Validation)

-- What communities exist, how large are they, which modules do they span?
SELECT CommunityId, Label, Size, Modules
FROM CATALOG.COMMUNITY_SUMMARY
ORDER BY Size DESC;

-- Which community does a specific element belong to?
SELECT c.AssetName, c.CommunityId, cs.Label, cs.Size
FROM CATALOG.COMMUNITIES c
JOIN CATALOG.COMMUNITY_SUMMARY cs ON c.CommunityId = cs.CommunityId
WHERE c.AssetName LIKE 'MyModule.%'
ORDER BY c.CommunityId;

-- Elements from your module that landed in a foreign community
-- (indicates tight coupling to that community's domain)
SELECT c.AssetName, cs.Label AS CommunityLabel
FROM CATALOG.COMMUNITIES c
JOIN CATALOG.COMMUNITY_SUMMARY cs ON c.CommunityId = cs.CommunityId
WHERE c.AssetName LIKE 'MyModule.%'
  AND cs.Label != 'MyModule'
ORDER BY cs.Label;

What to look for:

• If your module's elements are split across multiple communities, the module spans more than one bounded context — consider splitting it.
• If elements from module A consistently land in module B's community, module A has a hidden dependency on B's domain.
• Two communities both labeled the same marketplace module (e.g. AgentCommons appears twice) signals a natural internal split within that module.

Use Case 5: Finding Bridges (Centrality)

-- Top microflows by betweenness in your custom modules
-- High betweenness = bridge; breaking it disconnects subsystems
SELECT AssetName, PageRank, Betweenness
FROM CATALOG.GRAPH_CENTRALITY
WHERE AssetName LIKE 'MyModule.%'
   OR AssetName LIKE 'AnotherModule.%'
ORDER BY Betweenness DESC
LIMIT 20;

-- God nodes by PageRank (most influential, not just most-referenced)
SELECT Asset, ObjectType, ModuleName, InDegree, OutDegree, Degree
FROM CATALOG.GRAPH_GOD_NODES
WHERE ModuleName IN ('MyModule1', 'MyModule2')
ORDER BY Degree DESC
LIMIT 20;

Betweenness vs Degree:

• Degree (InDegree + OutDegree): raw connection count. High degree = popular or knows-too-much.
• Betweenness: fraction of shortest paths in the graph that pass through this node. High betweenness = bridge between clusters. A node can have low degree but high betweenness (a narrow connector between two large clusters).
• PageRank: recursive importance — being depended on by important things matters more than being depended on by many small things.

Use betweenness to find microflows where an interface change would require coordinating across many callers simultaneously.

Use Case 6: Entity Hotspots

-- Entities used by the most microflows, and across the most modules
SELECT Entity, UsedByFlows, AcrossModules
FROM CATALOG.GRAPH_ENTITY_HOTSPOTS
WHERE Entity LIKE 'MyModule.%'
ORDER BY UsedByFlows DESC;

An entity appearing in AcrossModules with 3+ module names is a candidate for an explicit service layer — instead of every module reading it directly, route access through a DS_ or SUB_ microflow in the owning module.