Module

A Module is a purpose-oriented building block of the tSM Platform.
While a Microservice describes a technical deployable, a Module groups everything users experience around a business domain:

• the primary microservice that powers it,
• domain configuration elements (forms, processes, listings, notifications, widgets),
• optional metadata and tags for governance and rollout.

Each module operates as an independent yet interoperable component on top of the shared tSM Core.

Typical uses:

• Product structuring — present clear domains in admin UI (e.g., Privisioning, Service Assureance, DMS, Notifications, Integrations).
• Configuration — add module-wide business configuration
• Packaging — collect all UI/automation assets that belong to one domain for simpler promotion across environments.
• Routing — record which microservice is the primary backend for a given domain.

Think of Modules as the what (business capability) and Microservices as the how (runtime unit).

---

Reference

Module (attributes)

Field	Type	Required	Read-only	Description / Notes
id	UUID	–	–	Identifier (not intended for end-user display).
code	String	Yes	–	Unique ASCII code (no spaces). Used in configuration and cross-references.
name	String	Yes	–	Display name shown in admin UI.
description	String	–	–	Optional longer description/tool-tip.
validityFrom/To	Date	–	–	Time window during which the module is considered active.
valid	Bool	–	Yes	Computed from validity; not stored.
modulType	String	–	–	Classification of the module type (taxonomy for your organization).
primaryMicroservice	String	–	–	Code of the Microservice that primarily implements this module.
formSpecification	Map	–	–	Extra form-level specifications for this module (key/value).
config	Map	–	–	Free-form configuration used by admin/UI tooling (not a deployment substitute).
dataTags	List	–	–	Labels for grouping/reporting (e.g., core, ops, external, pilot).
localizationData	Object	–	–	Translations for name/description.
auditInfo	Object	–	–	Standard audit metadata.

---

Good Practices

• Stable code — treat it as an immutable key referenced by configs and automations.
• One primary microservice — set primaryMicroservice for routing/ownership clarity; link others via documentation/tags.
• Keep config lightweight — UI hints and small flags only; runtime knobs belong to deployment (Kubernetes).
• Use validity for rollouts — stage modules with validityFrom/To across environments (DEV → UAT → PROD).
• Tag consistently — establish a small controlled vocabulary for dataTags to power dashboards and access controls.
• Bundle assets logically — store forms, processes, listings, notifications, and widgets under the module they belong to.

---

See Also

• System Settings: Microservice — technical services inventory (backend URLs, tags)
• Notifications, Logs, Attachments — common domain modules that appear in most installations
• tSM Core — shared foundations modules build upon