When to Use
- Publishing domain events after state changes
- Subscribing to events from other services
- Choosing a messaging backend for the project
- Implementing async workflows (notifications, emails, analytics)
Critical Patterns
| Pattern | Rule |
|---|---|
| Interface in domain | EventPublisher is a domain port |
| Implementation swappable | NATS, RabbitMQ, or Pub/Sub behind same interface |
| Events are immutable facts | Past tense: BookingCreated, PaymentCompleted |
| Events carry data | Include enough data so consumers don't need to call back |
| Idempotent consumers | Subscribers MUST handle duplicate messages |
| Cloud agnostic | Application layer never imports messaging SDK |
Event Definition (Domain)
Reference: assets/event.go
Domain Port
Reference: assets/port.go
NATS Implementation
Reference: assets/nats_publisher.go
Reference: assets/nats_subscriber.go
Topic Naming Convention
{service}.{domain}.{event}
Examples:
booking.booking.created
booking.booking.cancelled
payment.transaction.completed
caregiver.profile.verified
notification.email.requested
Publishing from Application Layer
Reference: assets/publish_usage.go
In-Memory Implementation (Testing)
Reference: assets/memory_publisher.go
Commands
# NATS
brew install nats-server
nats-server # Start locally
# Dependencies
go get github.com/nats-io/nats.go
# RabbitMQ alternative
docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:management
go get github.com/rabbitmq/amqp091-go
Anti-Patterns
| ❌ Don't | ✅ Do |
|---|---|
| Import NATS/RabbitMQ in domain | Define EventPublisher interface in domain |
Events named as commands (CreateBooking) | Events are past tense facts (BookingCreated) |
| Consumer calls back to producer service | Include enough data in the event payload |
| Assume exactly-once delivery | Design idempotent consumers |
| Synchronous event publishing blocking the request | Use goroutines or accept best-effort for non-critical events |