Skip to content

Implement Email Notification Orchestrator pattern with typed config, builders, renderer, and tests - #4

Open
imagineux wants to merge 1 commit into
mainfrom
codex/design-java-spring-boot-email-notification-service-iwr18f
Open

Implement Email Notification Orchestrator pattern with typed config, builders, renderer, and tests#4
imagineux wants to merge 1 commit into
mainfrom
codex/design-java-spring-boot-email-notification-service-iwr18f

Conversation

@imagineux

Copy link
Copy Markdown
Owner

Motivation

  • Provide a boring, low-cognitive-load pattern for producing email publication requests that centralizes the flow and makes adding new notifications trivial.
  • Keep per-notification code minimal and focused on model building rather than pipeline wiring.
  • Share rendering and publishing logic so the system is easy to maintain and reason about.

Description

  • Introduce typed configuration and catalog: NotificationType, NotificationDefinition, NotificationProperties (loaded via @ConfigurationProperties), and NotificationCatalog for lookups.
  • Add a single orchestration entry point EmailNotificationOrchestrator that loads config, resolves a builder from NotificationModelBuilderRegistry, renders via TemplateRenderer, builds an EmailPublicationRequest, and publishes via EmailPublicationPublisher.
  • Add model-builder pattern and registry: NotificationModelBuilder<T> plus concrete builders HoldListCreatedModelBuilder and HoldListRemovedModelBuilder to show extensibility without changing orchestration flow.
  • Provide shared renderer (TemplateRenderer + ThymeleafTemplateRenderer), a publisher contract (EmailPublicationPublisher), a logging publisher stub, example domain usage (HoldListDomainService), application.yml entries, Thymeleaf templates under resources/templates, and an expanded README with pattern rationale and checklist.

Testing

  • Added focused unit tests: EmailNotificationOrchestratorTest and NotificationModelBuilderRegistryTest which assert render/publish flow and payload-type safety respectively.
  • Attempted mvn test in this environment, but the run failed because Maven could not resolve the Spring Boot parent POM from Maven Central (HTTP 403), so tests did not execute here.
  • The added unit tests are designed to pass when dependencies are available and should validate the orchestration and registry behavior (EmailNotificationOrchestratorTest, NotificationModelBuilderRegistryTest).

Codex Task

@bolt-new-by-stackblitz

Copy link
Copy Markdown

Review PR in StackBlitz Codeflow Run & review this pull request in StackBlitz Codeflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant