Question: I am using [CqrsLite](https://github.com/gautema/CQRSlite) for a CQRS-style project. The Save method of the concrete Repository implementation looks like so (with irrelevant lines omitted).

```
    public void Save<T>(T aggregate, int? expectedVersion = null) where T : AggregateRoot
    {
        if (expectedVersion != null && _eventStore.Get(typeof(T), aggregate.Id, expectedVersion.Value).Any())
            throw new ConcurrencyException(aggregate.Id);

        var i = 0;
        foreach (var @event in aggregate.GetUncommittedChanges())
        {
            // ... [irrelevant code removed] ...
            _eventStore.Save(typeof(T), @event);
            _publisher.Publish(@event);
        }
        aggregate.MarkChangesAsCommitted();
    }

```

What's troubling me is that this method is committing events to be published to subscribers BEFORE the aggregate is told to mark them as committed. Thus, if an event handler that observes a given event chokes then the aggregate will not have committed changes that previous event handlers may have been notified of.

Why would I not move \_publisher.Publish(@event) to *after* aggregate.MarkChangesAsCommitted(), like so. What am I missing?

```
    public void Save<T>(T aggregate, int? expectedVersion = null) where T : AggregateRoot
    {
        if (expectedVersion != null && _eventStore.Get(typeof(T), aggregate.Id, expectedVersion.Value).Any())
            throw new ConcurrencyException(aggregate.Id);

        var events = aggregate.GetUncommittedChanges();
        foreach (var @event in events)
        {
            // ... [irrelevant code removed] ...
            _eventStore.Save(typeof(T), @event);
        }
        aggregate.MarkChangesAsCommitted();
        _publisher.Publish(events);
    }

```

Answer: 
**No matter which order of `Commit` and `Publish` you choose, you will have issues if the second one fails.**

There are multiple approaches to resolve this issue. Here are your main options:

1. Use a messaging infrastructure that uses the same database as your application, so that a single transaction can be used. This solution is viable when a very simple messaging infrastructure suffices, and the team decides to build it themselves.
2. Use 2 phase commits. This has a performance impact, which may or may not be relevant for your application.
3. Manually ensure you don't get into inconsistent states. See [this answer of mine](https://stackoverflow.com/questions/33117902/how-manage-transaction-between-domain-logic-and-events-in-ddd/33118597#33118597) for more information, I don't think it makes sense to copy the whole answer over.
This is an anti-pattern and you shouldn't be doing it.

Apparently putting a link prevents me from signing in as its a "suspicious request"

<https://www.youtube.com/watch?v=GbM1ghLeweU>