Postmark And Email Delivery Boundary
Summary
Postmark is a useful provider-boundary example for outbound communication. Email delivery should be exposed as a notification capability so stream policy, message intent, provider diagnostics, and caller signatures stay consistent.
Reader Question
How should a platform send operational email without letting every job choose provider settings, stream policy, retry behavior, and diagnostics on its own?
Boundary Pattern
Domain workflows create communication intent. Notification services decide how that intent becomes an email payload, which stream or channel policy applies, and which provider operation should be attempted. The provider integration adapts the external API and returns structured outcome information.
That separation keeps provider behavior out of business workflows. It also makes it possible to treat delivery failures as operational state when a domain workflow needs follow-up.
Reusable Lessons
- Email should be a capability, not an inline provider call.
- Stream policy is part of the service contract.
- Provider outcomes should be recorded in a stable internal shape.
- Retry behavior belongs near delivery state, not inside every caller.
- Notification services make channel changes possible later.
Source Evidence
docs/domains/notifications.mdservices/notifications/email.pyintegrations/ext_postmark