With the EventStore already implemented in the messaging system, it should be easy to add some pagination capabilities, query for Domain Events, and render a JSON or XML representation publishing a REST API. Why is that interesting? Well, distributed systems using messaging have to face many different problems, such as messages that don't arrive, messages that arrive duplicated, or messages that arrive in an unexpected order. That's why it's nice to provide an API to publish your Domain Events so that other Bounded Contexts can ask for some missing information. Just as an example, consider that you make an HTTP request to an /events endpoint. A possible result would be the following:

[
    {
        "id": 1,
        "version": 1,
        "typeName": "Lw\Domain\Model\User\UserRegistered",
        "eventBody": {
            "user_id": {
                "id": "459a4ffc-cd57-4cf0-b3a2-0f2ccbc48234"
            }
        },
        "occurredOn": {
            "date": "2016-05-26 06:06:07.000000",
            "timezone_type": 3,
            "timezone": "UTC"
        }
    },
    {
        "id": 2,
        "version": 2,
        "typeName": "Lw\Domain\Model\Wish\WishWasMade",
        "eventBody": {
            "wish_id": {
                "id": "9e90435a-395c-46b0-b4c4-d4b769cbf201"
            },
            "user_id": {
                "id": "459a4ffc-cd57-4cf0-b3a2-0f2ccbc48234"
            },
            "address": "[email protected]",
            "content": "This is my new wish!"
        },
        "occurredOn": {
            "date": "2016-05-26 06:06:27.000000",
            "timezone_type": 3,
            "timezone": "UTC"
        },
        "timeTaken": "650"
    },
    //...
]

As you can see in the previous example, we're exposing a set of Domain Events in a JSON REST API. In the output example, you can see a JSON representation of each of the Domain Events. There are some interesting points. First, the version field. Sometimes your Domain Events will evolve: they'll include more fields, they'll change the behavior of some existing fields, or they'll remove some existing fields. That's why it's important to add a version field in your Domain Events. If other Bounded Contexts are listening to such Events, they can use the version field to parse the Domain Event in different ways. You may have faced the same problem when versioning REST APIs.

Another point is the name. If you want to use the classname of the Domain Event, it may work in most cases. The problem is when a team decides to change the name of the class because of a refactoring. In this case, all Bounded Contexts listening to that name would stop working. This problem only occurs if you publish different Domain Events in the same queue. If you publish each Domain Event type in a different queue, it's not a real problem, but if you choose this approach, you'll face a different set of problems, such as receiving unordered events. Like in many other instances, there's a tradeoff involved. We strongly recommend you read Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. In this book, you'll learn different patterns for integrating multiple applications using asynchronous methods. Because Domain Events are messages sent in an integration channel, all messaging patterns also apply to them.