Implement shared email notification orchestration (Thymeleaf renderer, per-type builders)

[imagineux]

Motivation

• Centralize the email-notification flow so rendering, config lookup and publish logic are shared and boringly obvious.
• Make per-notification code minimal and focused on payload -> template model conversion to lower cognitive load when adding types.
• Drive notifications from typed configuration so behavior is visible in application.yml rather than scattered code.
• Provide a renderer and a publisher abstraction and avoid implementing delivery details (keep Kafka/topic producer out of this service).

Description

• Added a single entrypoint EmailNotificationOrchestrator and a light strategy interface NotificationModelBuilder<T> that are wired via constructor injection and a simple EnumMap registry.
• Added typed configuration classes NotificationProperties and NotificationDefinition plus NotificationCatalog for centralized lookup of notifications.email entries.
• Introduced a shared renderer abstraction TemplateRenderer and a Thymeleaf-backed ThymeleafTemplateRenderer, and an outgoing message EmailPublicationRequest with a publisher interface EmailPublicationPublisher (no delivery implementation).
• Included two example notifications (HOLD_LIST_CREATED, HOLD_LIST_REMOVED) with payload records, small builder components, templates under resources/templates, and a sample application.yml showing how to configure recipients/template/subject/enabled; also added focused unit tests for orchestrator behavior in src/test/java/....

Testing

• Added unit tests EmailNotificationOrchestratorTest that cover happy-path publish, skipping disabled notifications, multi-type support, and payload-type mismatch guards.
• Executed mvn test in this environment but the run failed due to dependency download issues (Maven Central returned HTTP 403 when fetching the Spring Boot parent POM), so the automated tests could not be completed here.
• The test sources are self-contained and exercise the orchestrator flow using test doubles for TemplateRenderer and EmailPublicationPublisher so they should pass once dependencies are available and Maven can download artifacts.

---

Codex Task

[bolt-new-by-stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: abece28ca8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Provide a concrete EmailPublicationPublisher bean

EmailNotificationOrchestrator is a @Service with a required constructor dependency on EmailPublicationPublisher, but a repo-wide search (rg in src/main/java) shows only the interface and no @Component/@Bean implementation. In this commit, that leaves the Spring context unable to create the orchestrator (and therefore HoldListDomainService), so the application will fail to start with an unsatisfied dependency.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Reject duplicate model builders per notification type

The constructor populates buildersByType with put but never checks for an existing entry, so if two NotificationModelBuilder beans return the same NotificationType, one silently overwrites the other. That can route notifications through the wrong builder based on bean ordering, producing incorrect models or runtime payload-type errors; this should fail fast on duplicate registrations.

Useful? React with 👍 / 👎.