Skip to content

Identity and shared services

Module id: shared

Users, messages, organisation, and the reference data every other module reuses.

Business modules call these services. They do not keep a private user store or a private list of countries.

Shared services in four groups: identity, notifications, organisation, and reference data
Read top to bottom. Identity, then notifications, then organisation, then reference data. Repository names for each group are in the tables below.

The picture names the four jobs. It does not list every repository. Those are below, including experience, domain, and core services, plus a few supporting repositories that are on disk but are not a fifth job.

What it owns

  • Users, roles, permissions, and external identities
  • Sessions, sign-in, and strong-authentication operations
  • Credentials and encryption keys
  • Notification send and preferences
  • Banks, branches, calendars, and tenant configuration
  • Reference data: countries, currencies, legal forms, and shared codes

What it does not own

  • The customer party. That is customers.
  • KYC and KYB cases. Those are onboarding.
  • Identity-provider toolkits and notification-channel vendors. Those stay behind adapters.
  • Product, agreement, and account records.

Identity

Repository Layer What it holds OpenAPI
exp-security Experience Channel security at /api/v1/experience/security openapi.yml
domain-core-security-center Domain Sign-in, sessions, users, permission checks openapi.yml
domain-common-sca Domain Strong-authentication operations openapi.yml
core-common-user-mgmt Core Users, roles, permissions, external identities openapi.yml
core-common-sca-mgmt Core Strong-authentication operation records openapi.yml
core-common-security-vault Core Credentials, versions, and encryption keys openapi.yml
app-authenticator Application Authenticator application No published OpenAPI

Sign-in and session queries live on domain-core-security-center (/api/v1/auth/login, logout, refresh, introspect, and session checks). The core stores the user. The experience service is the channel face.

Notifications

Repository Layer What it holds OpenAPI
exp-notifications Experience Notification centre at /api/v1/experience/notifications openapi.yml
domain-common-notifications Domain Send, bulk send, and preferences openapi.yml
core-common-notification-services Core Email, SMS, and push send openapi.yml

The domain decides what to send and stores preferences. The core performs the channel send. The vendor connection is an adapter concern, not a field on the business module.

Organisation and reference data

Repository Layer What it holds OpenAPI
exp-profile Experience Profile self-service at /api/v1/experience/profile openapi.yml
exp-channel-management Experience Channel init at /api/v1/experience/channel openapi.yml
domain-core-configuration Domain Tenant branding, languages, and lookup queries openapi.yml
core-common-org-mgmt Core Banks, branches, divisions, regions, calendars openapi.yml
core-common-config-mgmt Core Tenants, feature flags, provider parameters, webhooks openapi.yml
core-common-reference-master-data Core Countries, currencies, legal forms, lookups, and related codes openapi.yml

Profile self-service is an experience over the party and the user. It is not a second customer core. Channel init loads branding and reference data for a channel. The product catalogue itself stays in products.

Also on disk

These repositories are in the tree. They are not a separate module id.

Repository What it is OpenAPI
core-common-modelhub Dynamic entity definitions openapi.yml
core-data-template Template application with sample job-control paths api-spec/openapi.yml
domain-data-business-intelligence Repository present. README is a title only. No published OpenAPI
library-common-batch Batch scheduling utilities. No HTTP contract. No published OpenAPI

The template spec is a sample for job control. It is not a business-module contract.

How the pieces fit

A channel calls exp-security, exp-notifications, exp-profile, or exp-channel-management.

Identity commands and queries go through the security-centre domain into user, vault, and strong-authentication cores. Notification preferences and send requests go through the notification domain into the email, SMS, and push core. Organisation and reference data are core records that configuration queries read.

Full spec paths are also indexed under OpenAPI, shared services.