7.7 Topic Naming [Dido Solutions, Inc Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== 7.7 Topic Naming ======

[[fxdemo:05-part:start | Go To Top ]]

[[fxdemo:05-part:07-naming-and-file-conventions:start | Return to Naming and File Conventions ]]

[[dido:99_annexes:annex-b-terms-and-definitions:d:dds|DDS]] topic names should follow a consistent, architecture-facing convention. Topic names should identify the plane, domain, and subject of the topic.

The recommended topic naming pattern is:

''<Plane>.<Domain>.<Subject>''

Representative examples include:

  * ''Control.Node.Status''
  * ''Control.Node.Command''
  * ''Data.Reference.FxTransaction''
  * ''Data.Financial.CashFlow''
  * ''Data.Audit.Provenance''
  * ''Release.External.Package''

The first element should identify the plane or major interaction category. For Phase 0, the team should distinguish at least the [[dido:99_annexes:annex-b-terms-and-definitions:c:control_plane|Control Plane]] and [[dido:99_annexes:annex-b-terms-and-definitions:d:data_plane|Data Plane]] topics. If the implementation later adds release or external exchange topics, those names should remain consistent with the architectural meaning.

Topic names should use stable business or architectural concepts rather than implementation-specific class names. A topic name should not change because the team refactors a class, moves a file, or renames a container.

The team should document every Phase 0 topic in the Topic Catalogue. A topic should not enter the [[dido:99_annexes:annex-b-terms-and-definitions:b:baseline|Baseline]] unless the team can identify its purpose, data structure, participating [[dido:99_annexes:annex-b-terms-and-definitions:n:node|Nodes]], QoS expectations, and relationship to the Phase 0 demonstration.

----

<WRAP centeralign>

© 2026 Dido Solutions, Inc. and Jackrabbit Consulting, Inc.

</WRAP>