3

A lot of messaging frameworks have the term "topic". In a ddd microservice architecture, do these topics always reflect the domain events?

4
  • The "topics" to which messenger frameworks refer to are things like "Health Newsletter." You subscribe to the topic via the Publish/Subscribe pattern, and the messenger framework pushes messages to you from that topic area. Commented May 23, 2016 at 21:17
  • You might want to look at this link, and then flesh our your question further: stackoverflow.com/questions/32220312/… Commented May 23, 2016 at 21:29
  • 2
    An "event" in ddd would correspond to a message, not a topic area. The message would have a specific purpose; for example, the OrderCompletedEvent would notify the subscriber that an order has been completed. Commented May 23, 2016 at 21:29
  • Right, so it could be posted to a topic but that is out of scope for domain driven design?
    – Pepster
    Commented May 30, 2016 at 20:05

2 Answers 2

1

In AMQP lingo (the protocol behind e.g. RabbitMQ), a topic is a means of distributing messages, often implemented as a type of exchange ("topic exchange"). It is used to direct messages to subscribers using routing keys and routing patterns.

In our current project, DDD events travel in RabbitMQ messages. Our message routing keys are of the form : <emitting-bounded-context>.<entity-type>.<event-type> - for example, myContext.customer.created.

Depending on what they are interested in, clients can subscribe through queues bound by different routing patterns such as myContext.#, myContext.customer.*, etc.

So, domain events do not equal topics but they can have a matching "topic hierarchy value" in the messaging system, meaning that the event type may be somewhere in your tree of possible routing keys.

1
  • Forgive my pedantry but exchanges don't deliver to subscribers because you can't subscribe to an exchange. They deliver to zero or more queues, and those are are how subscribers receive their messages. Commented Jun 3, 2021 at 0:04
0

The most accurate answer to "do these topics always reflect domain events", the answer is "no, not always, but sometimes they will".

Some definitions:

  • Domain Events are defined in the domain layer, and they are a first class citizen of the domain. They may directly hold references to domain entities and value objects. Handlers can be defined that will be invoked when the domain event is raised.
  • A Topic is a concept used by some pub/sub systems that allow subscriber systems to subscribe to the topic and receive all messages sent to that topic. It can be described as a 'logical channel' for messages and permits 'fanout' architecture for messaging.

You can certainly use a topic to reflect a domain event, as the pub/sub model for messages sent to the topic maps well to the concept of subscribing to handle an event - but that is not the only thing a topic can be used for - it might be a more general grouping of messages, rather than a specific event.

If you do choose to create topics for each event to reflect domain events, whether or not you need a topic for a given domain event depends on whether or not you want that domain event published outside the current bounded context as part of the published language of the context, or if you want to keep it internal to the domain, only usable within the domain itself - both are valid depending on the event.

One way of thinking about it is in terms of the hexagonal architecture (aka 'ports and adapters'). In this architecture, the boundary to the world the application is an adapter - typical adapters include a REST API, a Messaging system, or a persistence system.

In this analogy, a topic is more like a URI endpoint.

You typically don't expose all your entities via REST API endpoints - and when you do, you don't expose the entity exactly as it is defined in the domain, you expose it in a format suitable for that adapter.

Similarly, you won't necessarily expose all your domain events via topics - and when you do, you won't expose the event exactly as it is defined in the domain event, you'd expose it in a format suitable for the topic messaging.

e.g. a Domain Event might hold a reference to two separate entities. The message sent to the topic might be a json blob with two entity IDs

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.