Skip to content
Phero Lang
Menu

Demo / the semantic graph

One domain, eight perspectives.

A business system is one connected semantic model. The layers people experience as separate artifacts — the domain, the decisions, the policy, the workflow, the interface, the deployment — are views of that one model, and they can be checked against each other because they are stored together.

Everything below is drawn from the compiled artifacts of the support-desk example in this repository. Nothing here is an illustration of what the graph might look like.

8

Perspectives

10

Source files

140

Nodes

232

Connections

The explorer

Pick a layer, then a node.

The row of perspectives is a tablist. Tab reaches it, the arrow keys and Home and End move inside it, and Tab again lands in the drawing, where every node is a button: Enter or Space shows its kind, its declaration file, its connections and its artifact id, and Escape clears the selection.

Domain Decisions Events Workflows Authorisation Experience Deployment Cases

Each perspective is also a link to its panel: without JavaScript all eight layers stay readable, and with it the row above behaves as a tablist.

Domain perspective of support/cli.ifmlDomain perspective of support/cli.ifml: 20 nodes and 23 connections, from the committed graph artifact. Nodes are grouped in columns: nz.example.support (4), nz.example.support.RefundDecision (3), nz.example.support.Ticket (9), nz.example.support.User (4). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.nz.example.supportnz.example.support.RefundDecisionnz.example.support.Ticketnz.example.support.UserRefundDecision is a class declared in support/support.mox, with 3 connections shown in this view.RefundDecision classTicket is a class declared in support/support.mox, with 12 connections shown in this view.Ticket classUser is a class declared in support/support.mox, with 7 connections shown in this view.User classTicketState is an enum declared in support/support.mox, with one connection shown in this view.TicketState enumapproved is a feature declared in support/support.mox, with one connection shown in this view.approved featurecents is a feature declared in support/support.mox, with one connection shown in this view.cents featuredecisionId is a feature declared in support/support.mox, with one connection shown in this view.decisionId featureassignee is a feature declared in support/support.mox, with 4 connections shown in this view.assignee featureinternal is a feature declared in support/support.mox, with one connection shown in this view.internal featureneedsRefund is a feature declared in support/support.mox, with one connection shown in this view.needsRefund featurerefundCents is a feature declared in support/support.mox, with one connection shown in this view.refundCents featurestate is a feature declared in support/support.mox, with 2 connections shown in this view.state featureticketNo is a feature declared in support/support.mox, with one connection shown in this view.ticketNo featuretitle is a feature declared in support/support.mox, with one connection shown in this view.title featureapproveRefund is an operation declared in support/support.mox, with one connection shown in this view.approveRefund operationraiseRefund is an operation declared in support/support.mox, with one connection shown in this view.raiseRefund operationactive is a feature declared in support/support.mox, with one connection shown in this view.active featureassignedTickets is a feature declared in support/support.mox, with 4 connections shown in this view.assignedTickets featurename is a feature declared in support/support.mox, with one connection shown in this view.name featureuserId is a feature declared in support/support.mox, with one connection shown in this view.userId feature
Domain20 nodes, 23 connections · scroll sideways for the full diagram
Decisions perspective of support/cli.ifmlDecisions perspective of support/cli.ifml: 10 nodes and 10 connections, from the committed graph artifact. Nodes are grouped in columns: RefundDecisions (10). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.RefundDecisionsRefundDecisions is a decision model declared in support/support.dmn, with 9 connections shown in this view.RefundDecisions decision modelRefundAssessment is a decision declared in support/support.dmn, with 2 connections shown in this view.RefundAssessment decisionRefundAuthority is a decision declared in support/support.dmn, with one connection shown in this view.RefundAuthority decisionRefundEligibility is a decision declared in support/support.dmn, with one connection shown in this view.RefundEligibility decisionAssessRefund is a decision service declared in support/support.dmn, with 2 connections shown in this view.AssessRefund decision serviceassess_refund is a business knowledge model declared in support/support.dmn, with one connection shown in this view.assess_refund business knowledge modelConsumerGuaranteesAct is a knowledge source declared in support/support.dmn, with one connection shown in this view.ConsumerGuaranteesAct knowledge sourcehelper is an input data node declared in support/support.dmn, with one connection shown in this view.helper input datarequested_cents is an input data node declared in support/support.dmn, with one connection shown in this view.requested_cents input dataticket is an input data node declared in support/support.dmn, with one connection shown in this view.ticket input data
Decisions10 nodes, 10 connections · scroll sideways for the full diagram
Events perspective of support/cli.ifmlEvents perspective of support/cli.ifml: 8 nodes and 9 connections, from the committed graph artifact. Nodes are grouped in columns: support (8). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.supportRefundApproved is an event declared in support/support.evt, with 2 connections shown in this view.RefundApproved eventRefundRequested is an event declared in support/support.evt, with 3 connections shown in this view.RefundRequested eventTicketRaised is an event declared in support/support.evt, with 2 connections shown in this view.TicketRaised eventTicketResolved is an event declared in support/support.evt, with 2 connections shown in this view.TicketResolved eventrefunds is a channel declared in support/support.evt, with 2 connections shown in this view.refunds channeltickets is a channel declared in support/support.evt, with 2 connections shown in this view.tickets channelanalytics is a subscription declared in support/support.evt, with 3 connections shown in this view.analytics subscriptionrefundDesk is a subscription declared in support/support.evt, with 2 connections shown in this view.refundDesk subscription
Events8 nodes, 9 connections · scroll sideways for the full diagram
Workflows perspective of support/cli.ifmlWorkflows perspective of support/cli.ifml: 28 nodes and 29 connections, from the committed graph artifact. Nodes are grouped in columns: SupportDesk (3), SupportDesk.desk (3), SupportDesk.desk.TicketRepository (7), SupportDesk.desk.TicketService (15). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.SupportDeskSupportDesk.deskSupportDesk.desk.TicketRepositorySupportDesk.desk.TicketServicedesk is a module declared in support/support.ddd, with 4 connections shown in this view.desk modulepeople is a module declared in support/support.ddd, with one connection shown in this view.people moduleSupportDesk is a design application declared in support/support.ddd, with 2 connections shown in this view.SupportDesk design applicationTicketService is a service declared in support/support.ddd, with 17 connections shown in this view.TicketService serviceTicketRepository is a repository declared in support/support.ddd, with 9 connections shown in this view.TicketRepository repositoryTicketSearch is a search declared in support/support.ddd, with one connection shown in this view.TicketSearch searchdelete is a repository operation declared in support/support.ddd, with 2 connections shown in this view.delete repository operationfindAll is a repository operation declared in support/support.ddd, with one connection shown in this view.findAll repository operationfindByExample is a repository operation declared in support/support.ddd, with one connection shown in this view.findByExample repository operationfindById is a repository operation declared in support/support.ddd, with one connection shown in this view.findById repository operationfindByKeys is a repository operation declared in support/support.ddd, with one connection shown in this view.findByKeys repository operationfindByTitle is a repository operation declared in support/support.ddd, with one connection shown in this view.findByTitle repository operationsave is a repository operation declared in support/support.ddd, with one connection shown in this view.save repository operationapprove is a service operation declared in support/support.ddd, with one connection shown in this view.approve service operationapproveRefund is a service operation declared in support/support.ddd, with one connection shown in this view.approveRefund service operationassign is a service operation declared in support/support.ddd, with one connection shown in this view.assign service operationclaimTicket is a service operation declared in support/support.ddd, with one connection shown in this view.claimTicket service operationclose is a service operation declared in support/support.ddd, with 2 connections shown in this view.close service operationfindTickets is a service operation declared in support/support.ddd, with one connection shown in this view.findTickets service operationgetTicket is a service operation declared in support/support.ddd, with one connection shown in this view.getTicket service operationlistTickets is a service operation declared in support/support.ddd, with one connection shown in this view.listTickets service operationmarkRead is a service operation declared in support/support.ddd, with one connection shown in this view.markRead service operationraise is a service operation declared in support/support.ddd, with one connection shown in this view.raise service operationraiseRefund is a service operation declared in support/support.ddd, with one connection shown in this view.raiseRefund service operationrefundTicket is a service operation declared in support/support.ddd, with one connection shown in this view.refundTicket service operationreject is a service operation declared in support/support.ddd, with one connection shown in this view.reject service operationresolveTicket is a service operation declared in support/support.ddd, with one connection shown in this view.resolveTicket service operationupdateTicket is a service operation declared in support/support.ddd, with one connection shown in this view.updateTicket service operation
Workflows28 nodes, 29 connections · scroll sideways for the full diagram
Authorisation perspective of support/cli.ifmlAuthorisation perspective of support/cli.ifml: 9 nodes and 13 connections, from the committed graph artifact. Nodes are grouped in columns: Support (9). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.SupportAgent is an actor declared in support/support.actor, with 5 connections shown in this view.Agent actorCustomer is an actor declared in support/support.actor, with 2 connections shown in this view.Customer actorFinance is an actor declared in support/support.actor, with 2 connections shown in this view.Finance actorManager is an actor declared in support/support.actor, with 4 connections shown in this view.Manager actorApproveRefund is a capability declared in support/support.actor, with 3 connections shown in this view.ApproveRefund capabilityRaiseRefund is a capability declared in support/support.actor, with 3 connections shown in this view.RaiseRefund capabilityReadTicket is a capability declared in support/support.actor, with 3 connections shown in this view.ReadTicket capabilityResolveTicket is a capability declared in support/support.actor, with 2 connections shown in this view.ResolveTicket capabilityUpdateTicket is a capability declared in support/support.actor, with 2 connections shown in this view.UpdateTicket capability
Authorisation9 nodes, 13 connections · scroll sideways for the full diagram
Experience perspective of support/cli.ifmlExperience perspective of support/cli.ifml: 25 nodes and 23 connections, from the committed graph artifact. Nodes are grouped in columns: Inbox (1), Queue (3), cli (6), support (12), tickets (3). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.InboxQueueclisupportticketsescalations is a component declared in support/support.ifml, with one connection shown in this view.escalations componentassessment is a component declared in support/support.ifml, with 0 connections shown in this view.assessment componentintake is a component declared in support/support.ifml, with one connection shown in this view.intake componentrefunds is a component declared in support/support.ifml, with one connection shown in this view.refunds componentcli is an interaction flow declared in support/cli.ifml, with 5 connections shown in this view.cli interaction flowClaimTicket is an action declared in support/cli.ifml, with 2 connections shown in this view.ClaimTicket actionGetTicket is an action declared in support/cli.ifml, with 2 connections shown in this view.GetTicket actionListTickets is an action declared in support/cli.ifml, with 2 connections shown in this view.ListTickets actionRefundTicket is an action declared in support/cli.ifml, with 2 connections shown in this view.RefundTicket actiontickets is a command declared in support/cli.ifml, with 2 connections shown in this view.tickets commandsupport is an interaction flow declared in support/support.ifml, with 11 connections shown in this view.support interaction flowFolder is a view declared in support/support.ifml, with one connection shown in this view.Folder viewInbox is a view declared in support/support.ifml, with one connection shown in this view.Inbox viewItemDetail is a view declared in support/support.ifml, with one connection shown in this view.ItemDetail viewQueue is a view declared in support/support.ifml, with 2 connections shown in this view.Queue viewWorkItem is a view declared in support/support.ifml, with one connection shown in this view.WorkItem viewApprove is an action declared in support/support.ifml, with one connection shown in this view.Approve actionApproveRefund is an action declared in support/support.ifml, with 2 connections shown in this view.ApproveRefund actionAssign is an action declared in support/support.ifml, with one connection shown in this view.Assign actionMarkRead is an action declared in support/support.ifml, with one connection shown in this view.MarkRead actionRaiseRefund is an action declared in support/support.ifml, with 2 connections shown in this view.RaiseRefund actionReject is an action declared in support/support.ifml, with one connection shown in this view.Reject actionclaim is a command declared in support/cli.ifml, with one connection shown in this view.claim commandrefund is a command declared in support/cli.ifml, with one connection shown in this view.refund commandshow is a command declared in support/cli.ifml, with one connection shown in this view.show command
Experience25 nodes, 23 connections · scroll sideways for the full diagram
Deployment perspective of support/cli.ifmlDeployment perspective of support/cli.ifml: 10 nodes and 11 connections, from the committed graph artifact. Nodes are grouped in columns: SupportDesk (10). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.SupportDeskedgeLive is a deployment declared in support/support.deploy, with 2 connections shown in this view.edgeLive deploymentproduction is a deployment declared in support/support.deploy, with 2 connections shown in this view.production deploymentSupportDesk is a deployment application declared in support/support.deploy, with 7 connections shown in this view.SupportDesk deployment applicationanalytics_service is a deployment component declared in support/support.deploy, with one connection shown in this view.analytics_service deployment componentapi is a deployment component declared in support/support.deploy, with 3 connections shown in this view.api deployment componentdb is a deployment component declared in support/support.deploy, with 2 connections shown in this view.db deployment componentrefund_approval_service is a deployment component declared in support/support.deploy, with one connection shown in this view.refund_approval_service deployment componentweb is a deployment component declared in support/support.deploy, with 2 connections shown in this view.web deployment componentedge is a deployment profile declared in support/support.deploy, with one connection shown in this view.edge deployment profileproduction_k8s is a deployment profile declared in support/support.deploy, with one connection shown in this view.production_k8s deployment profile
Deployment10 nodes, 11 connections · scroll sideways for the full diagram
Cases perspective of support/cli.ifmlCases perspective of support/cli.ifml: 20 nodes and 17 connections, from the committed graph artifact. Nodes are grouped in columns: RefundDesk (14), support (6). Every node is labelled with its short name and its kind; a line joins two nodes the graph connects.RefundDesksupportRefundDesk is a case declared in support/support.cmmn, with 13 connections shown in this view.RefundDesk caseApproveRefund is a plan item declared in support/support.cmmn, with 2 connections shown in this view.ApproveRefund plan itemAssessAuthority is a plan item declared in support/support.cmmn, with one connection shown in this view.AssessAuthority plan itemAssessRefund is a plan item declared in support/support.cmmn, with one connection shown in this view.AssessRefund plan itemAssessment is a plan item declared in support/support.cmmn, with one connection shown in this view.Assessment plan itemCloseTicket is a plan item declared in support/support.cmmn, with 2 connections shown in this view.CloseTicket plan itemEscalate is a plan item declared in support/support.cmmn, with 2 connections shown in this view.Escalate plan itemRefundSettled is a plan item declared in support/support.cmmn, with one connection shown in this view.RefundSettled plan itemReviewTicket is a plan item declared in support/support.cmmn, with 2 connections shown in this view.ReviewTicket plan itemdecision is a case-file item declared in support/support.cmmn, with one connection shown in this view.decision case-file itemticket is a case-file item declared in support/support.cmmn, with one connection shown in this view.ticket case-file itemescalation is a case role declared in support/support.cmmn, with 2 connections shown in this view.escalation case rolefinance is a case role declared in support/support.cmmn, with 2 connections shown in this view.finance case roletriage is a case role declared in support/support.cmmn, with 3 connections shown in this view.triage case roleApproveRefund is a use case declared in support/support.uc, with 0 connections shown in this view.ApproveRefund use caseClarifyTicket is a use case declared in support/support.uc, with 0 connections shown in this view.ClarifyTicket use caseEscalateInternal is a use case declared in support/support.uc, with 0 connections shown in this view.EscalateInternal use caseMonitorQueue is a use case declared in support/support.uc, with 0 connections shown in this view.MonitorQueue use caseRaiseRefund is a use case declared in support/support.uc, with 0 connections shown in this view.RaiseRefund use caseTrackRefund is a use case declared in support/support.uc, with 0 connections shown in this view.TrackRefund use case
Cases20 nodes, 17 connections · scroll sideways for the full diagram

What you are looking at

One application, read eight ways

One application, 10 files, 140 nodes and 232 connections. Each perspective below is the same application read through one surface; the counts are the drawing's, not a separate tally.

The ten source files are the nine surfaces plus a second interaction flow (cli.ifml), which declares the command-line views over the same domain. Every one of them is compiled, and every one of them contributes nodes to the same graph.

  • support/cli.ifml
  • support/support.actor
  • support/support.cmmn
  • support/support.ddd
  • support/support.deploy
  • support/support.dmn
  • support/support.evt
  • support/support.ifml
  • support/support.mox
  • support/support.uc

The drawing leaves out the 10 file nodes — a file is a container, not a declaration — which leaves 130 nodes. Of the 232 connections, 20 touch a file node and 77 join two different layers (an interface action binding a service operation, say), so the perspectives carry the remaining 135: the ones whose two ends sit in the same layer.

A node id is the graph artifact's id verbatim, so a node selected above can be found with pherolang graph query in the committed artifact. It is not a label invented for this page.

The eight perspectives of the support application, the surface each one is drawn from, and the node and connection counts of each drawing.
PerspectiveSurfaceNodesEdges
DomainDomain model.mox2023
DecisionsDecision model.dmn1010
EventsEvent contract.evt89
WorkflowsApplication design.ddd2829
AuthorisationAuthorisation.actor913
ExperienceInteraction flow.ifml2523
DeploymentDeployment.deploy1011
CasesCase management.cmmn2017

The same corpus holds 8 import-connected applications, 305 nodes and 463 edges. This page filters to one of them, because a graph of everything would not fit on a screen or in a sentence.

Provenance

Generated, not illustrated

The drawing is a projection of one committed artifact. Regenerate the artifact and the projection, and the numbers on this page change with them.

site/data/graph.json is written by the released pherolang binary running graph build over examples/. The builder is derived post-compile: it never re-reads a source or re-checks a file, so a node in the graph is a node the compiler produced.

The artifact is pinned: examples/artifacts/examples.graph.json is byte-compared in CI against a fresh build of the same tree, so a change to the graph is a change to a committed golden, not a silent drift.

site/scripts/render-graph.mjs then bakes the per-perspective geometry into site/data/support-model.json, which is what this page reads. Detail paths are relative to the repository's examples/ directory.

The architecture pageGraph reference
repository root
pherolang graph build examples -o examples.graph.json
diff examples.graph.json examples/artifacts/examples.graph.json   # what CI checks
node site/scripts/sync-model.mjs                                  # project it into site/data/

The first line is the exact command scripts/check-commands.mjs executes in CI; the diff is the freshness gate. Node kinds, edge kinds, determinism and the query surface are documented in the graph reference.