Задержка создания и отправки доменных событий

Одно из решений (предложенное @synhershko) — перенести диспетчеризацию событий домена за пределы домена. Таким образом, мы можем убедиться, что наша сущность сохраняется, прежде чем мы вызовем какие-либо события.

Однако теперь мы перемещаем поведение из домена (где оно принадлежит) в наше приложение только для того, чтобы обойти нашу технологию постоянства, что меня не очень радует.

Мое решение проблемы События должны отправляться только в том случае, если объект успешно сохранен, заключался в создании отложенного диспетчера событий, который ставит события в очередь. Затем мы внедряем диспетчер в нашу единицу работы, гарантируя, что мы сначала сохраняем/сохраняем нашу сущность, а затем генерируем события предметной области:

public class DeferredEventDispatcher : IEventDispatcher
{
    private readonly IEventDispatcher inner;
    private readonly ConcurrentQueue<Action> events = new ConcurrentQueue<Action>();

    public DeferredEventDispatcher(IEventDispatcher inner)
    {
        this.inner = inner;
    }

    public void Dispatch<TEvent>(TEvent e)
    {
        events.Enqueue(() => inner.Dispatch(e));
    }

    public void Resolve()
    {
        Action dispatch;
        while (events.TryDequeue(out dispatch))
        {
            dispatch();
        }
    }
}

public class UnitOfWork
{
    public void Commit()
    {
        session.SaveChanges();
        dispatcher.Resolve(); // raise events
    }
}

По сути, это достигает того же, что и предложено @synhershko, но сохраняет «поднятие» событий в моем домене.

Что касается события не должны создаваться до тех пор, пока объект не будет сохранен, основная проблема заключалась в том, что идентификаторы объектов устанавливались RavenDB извне. Решение, которое держит мой домен в неведении и легко проверяется, состоит в том, чтобы просто передать идентификатор в качестве параметра конструктора. Это то, что я бы сделал, если бы использовал базу данных SQL (обычно передавая Guid).

К счастью, RavenDB предоставляет вам возможность генерировать идентификаторы с использованием стратегии hilo (чтобы мы могли сохранить идентификаторы RESTful). Это из проекта RavenDB Contrib:

public static string GenerateIdFor<T>(this IAdvancedDocumentSessionOperations session)
{
    // An entity instance is required to generate a key, but we only have a type.
    // We might not have a public constructor, so we must use reflection.
    var entity = Activator.CreateInstance(typeof(T), true);

    // Generate an ID using the commands and conventions from the current session
    var conventions = session.DocumentStore.Conventions;
    var databaseName = session.GetDatabaseName();
    var databaseCommands = session.GetDatabaseCommands();
    return conventions.GenerateDocumentKey(databaseName, databaseCommands, entity);
}

Затем я могу использовать это для создания идентификатора и передачи его в мои конструкторы сущностей:

var orderId = session.GenerateIdFor<Order>();
var order = new Order(orderId, 1.99M);

Следуя нашему обсуждению в Твиттере, вместо того, чтобы делать это из конструктора Order, я просто сделаю это:

var order = new Order(amount: 10);
session.Store(order);
DomainEvents.Raise(new OrderRaisedEvent { OrderId = order.Id });

session.SaveChanges();

Еще лучше — вы можете создать IDocumentStoreListener и сделать это оттуда в зависимости от сохраняемого типа. Я не вижу причин делать это из конструктора - вы хотите вызвать событие, когда заказ был сохранен (или отправлен для сохранения), а не при создании его представления в памяти.

Поскольку это будет использовать генератор HiLo внутри, вам гарантировано, что это не будет обращаться к БД для каждого вызова Store(), и что идентификаторы будут уникальными. Поэтому, если что-то пойдет не так, будет получено сообщение с идентификатором заказа, и когда после нескольких попыток не будет найден заказ с этим идентификатором, вы можете предположить, что что-то пошло не так с его сохранением. Или вы можете попытаться поймать исключения и вызвать другое событие с деталями исключения, имеющими идентификатор этого заказа.

Попытка совместить отправку сообщений и хранение документов в RavenDB в рамках одной и той же транзакции — это действительно излишество. Вместо этого вы должны планировать и строить на случай неудач.