add-ideas/govoplan-campaign
1
0
Fork 0
Code Issues 49 Pull Requests Actions Packages Projects Releases Wiki Activity
Page: Repo docs RECIPIENT ADDRESS BOUNDARY
Pages
Codex Project Index Repo README Repo docs CAMPAIGN DELIVERY RUNBOOK Repo docs EXAMPLE CAMPAIGNS AND RELEASE CHECKLIST Repo docs RECIPIENT ADDRESS BOUNDARY Repo docs RECIPIENT IMPORT GUIDE
Clone
1
Repo docs RECIPIENT ADDRESS BOUNDARY
Albrecht Degering edited this page 2026-07-09 12:34:40 +02:00
Table of Contents

Mirrored from /mnt/DATA/git/govoplan-campaign/docs/RECIPIENT_ADDRESS_BOUNDARY.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

Recipient And Address Management Boundary

Campaigns currently own campaign-local recipient entries because sending and reporting need a frozen recipient snapshot. Long-lived address management is a separate domain and should move to govoplan-addresses.

govoplan-campaign Owns

  • campaign-local recipient entries
  • campaign-local recipient import mapping and validation
  • message addressing for a concrete campaign version
  • send/build/report evidence for the exact recipients used
  • campaign-local exclusions, warnings, and review status
  • recipient-specific attachment and template evidence

Campaign data is immutable once a version is built for sending. Later address book changes must not rewrite historical campaign evidence.

govoplan-addresses Should Own

  • Adrema-style address management
  • reusable person, organization, household, and postal-address records
  • reusable email address lists and segments
  • postal-letter recipient views
  • consent, legal-basis, and communication-preference metadata
  • deduplication and merge workflows
  • import/export of reusable address directories
  • address quality checks and change history

The addresses module should provide stable DTOs and capabilities that campaigns, mail, forms, reporting, portal, and postbox modules can consume without direct imports.

Integration Contract

The campaign module should ask the platform whether the addresses module is installed. When present, campaign can offer address-source choices through a capability such as addresses.recipientSource.

The capability should return snapshots, not live ORM objects:

  • selected source id and display label
  • normalized recipient rows
  • provenance fields for source, segment, legal basis, and import time
  • update markers so campaigns can show whether a draft is based on stale source data

Campaign stores the resolved snapshot in the campaign version. It may keep a reference to the address source for traceability, but the built campaign remains auditable even if the address source changes later.

Non-Goals For Campaign

Campaign should not become the global address book. It should not own:

  • deduplication across campaigns
  • consent lifecycle
  • master-data merge policy
  • address-directory permissions beyond campaign use
  • postal address normalization
  • reusable segmentation rules

Those belong in govoplan-addresses or a dedicated records/identity module when the domain needs stronger governance.