# Golee messaging

## Ubiquitous language

**Topics**
A named resource to which messages are sent by publishers.

**Subscription**
A named resource representing the stream of messages from a single, specific topic, to be delivered to the subscribing application.
- A subscription can only be linked to one topic
- A subscription can be listened to by several subscribers, but each message will be delivered to only one of them.
- If a topic has N subscriptions, the topic's messages will be replicated in all N subscriptions.

**Message**
The combination of data and (optional) attributes that a publisher sends to a topic and is eventually delivered to subscribers.

**Publisher**
An application that creates and sends messages to a topic(s)

**Subscriber**
An application with a subscription to a topic(s) to receive messages from it.

**Acknowledgement**
A signal sent by a subscriber to Pub/Sub after it has received a message successfully. Acked messages are removed from the subscription's message queue.

---
## Topic patterns

**Pattern 1: topic x action**
There is ONE topic for env, service, bounded contenxt and action. (es *prod.people.profile-linked-to-user*, *prod.people.profile-deleted*, *staging.club.organization-owned* ecc ecc). If there are 3 envs, with 20 services each 5 bounded context with 10 actions per context there will be 3000 topics.
Subscriptions are topic-specific. So it will be possible to replay events per action, and not per bounded context.

PRO
- subscriptions are very specific, it is possible to diversify them by single action. (*es by setting different dead letter policies per action.*)

CONS
- It is not possible to order events at bounded context level but only at action level
- It is not possible to replay events at bounded context level, but only at action level.
- There is a high number of subscriptions per service. (*es. if a service is interested in 5 bounded contexts each with 5 actions has 25 active subscriptions*)
- The number of subscriptions and topics increases directly with the number of events in the domain.

**Pattern 2: topic x bounded context**
There is ONE topic for env, service and bounded context. (es *prod.people.profile*, *prod.club.organization*, *staging.people.athelte*).
If there are 3 envs, with 20 services each 5 bounded context with 10 actions per context there will be 300 topics.

PRO
- subscriptions can be specific with filtering feature, it is possible to diversify them by single action. (*es by setting different dead letter policies per action.*)
- less subscriptions x service
- messages can be ordered for bounded context
- messages can be replayed for bounded context

CONS
- action is passed as message attribute
- each event defined on service sdk has topic and action. (es *profile-created* will be `{topic: "prod.people.profile", action: "profile-created"}`)

---
## Naming convension

**Topic** name with pattern 1 is `<env>.<service>.<bounded-context>-<action>`. (es. *prod.people.profile-linked-to-user*)

**Topic** name with pattern 2 is `<env>.<service>.<bounded-context>`. (es. *prod.people.profile*). Action in messages attribute is `<bounded-context>-<action>`. (es. *profile-created*)

**Subscription** name is `<env>.<service>.<subscriber-module>`. (es *prod.bayes.hubspot-connector*)