Полученный событием совокупный корень должен иметь доступ к репозиторию определения источника события?

Я работаю над полученной событием реализацией CQRS, с помощью DDD в приложении / доменный слой. У меня есть объектная модель, которая похожа на это:

public class Person : AggregateRootBase
{
    private Guid? _bookingId;

    public Person(Identification identification)
    {
        Apply(new PersonCreatedEvent(identification));
    }

    public Booking CreateBooking() {
        // Enforce Person invariants
        var booking = new Booking();
        Apply(new PersonBookedEvent(booking.Id));
        return booking;
    }

    public void Release() {
        // Enforce Person invariants
        // Should we load the booking here from the aggregate repository?
        // We need to ensure that booking is released as well.
        var booking = BookingRepository.Load(_bookingId);
        booking.Release();
        Apply(new PersonReleasedEvent(_bookingId));
    }

    [EventHandler]
    public void Handle(PersonBookedEvent @event) { _bookingId = @event.BookingId; }

    [EventHandler]
    public void Handle(PersonReleasedEvent @event) { _bookingId = null; }
}

public class Booking : AggregateRootBase
{
    private DateTime _bookingDate;
    private DateTime? _releaseDate;

    public Booking()
    {
        //Enforce invariants
        Apply(new BookingCreatedEvent());
    }

    public void Release() 
    {
        //Enforce invariants
        Apply(new BookingReleasedEvent());
    }

    [EventHandler]
    public void Handle(BookingCreatedEvent @event) { _bookingDate = SystemTime.Now(); }
    [EventHandler]
    public void Handle(BookingReleasedEvent @event) { _releaseDate = SystemTime.Now(); }
    // Some other business activities unrelated to a person
}

С моим пониманием DDD до сих пор, и Человек и Заказ являются отдельным агрегатом, поддерживает две причины:

1. Существуют времена, когда бизнес-компоненты вытянут объекты Заказа отдельно от базы данных. (т.е., у человека, который был выпущен, есть предыдущий заказ, измененный из-за неправильной информации).
2. Там не должен блокировать конкуренцию между Человеком и Заказывать каждый раз, когда Заказ должен быть обновлен.

Еще одно бизнес-требование состоит в том, что Заказ никогда не может происходить для Человека несколько раз за один раз. Из-за этого, я обеспокоен запросами базы данных запроса по стороне чтения, поскольку могло потенциально быть некоторое несоответствие там (из-за использования CQRS и наличия в конечном счете последовательной базы данных чтения).

Совокупным корням нужно позволить запросить полученное событием запоминающее устройство идентификатором для объектов (ленивая загрузка их по мере необходимости)? Есть ли какие-либо другие пути реализации, которая имела бы больше смысла?