Why is my command event string field being retrieved as null

Question

I am writing my first EventStore test app, I am re-hydrating my object from a stream, and whilst it gets the numberSold correctly, the title is null, and I don't understand why - the command when retrieved from the stream has the title set as null but I am sure it is being written OK.

Can a fresh pair of eyes see what I am doing wrong?

private static void Main()
{
    using (store = WireupEventStore())
    {
        var newBook = new Book("my book", 0);
        newBook.ChangeBookName("renamed book");
        newBook.AdjustBooksSold(5);
        var idToRetrieveLater = newBook.bookId;

        var bookRepo = new BookRepository(store);
        bookRepo.Put(newBook);

        var bookReadBack = bookRepo.Get(idToRetrieveLater);
        // book name is set to null here, but count==5 is OK
}

Book class

public class Book
{ 
    public readonly Guid bookId;
    private int numberSold;
    private string title { get; set; }
    private List<object> eventsToCommit = new List<object>();

    public Book(string title, int sold)
    {
        this.bookId = Guid.NewGuid();
        this.title = title;
        this.numberSold = sold;
    }

    public Book(Guid id, IEnumerable<EventMessage> events)
    {
        this.bookId = id;
        foreach (var ev in events)
        {
            dynamic @eventToCall = ev.Body;
            Apply(@eventToCall);
        }
    }

    public void ChangeBookName(string name)
    {
        var nameChanged = new BookNameChanged(this.bookId, name);
        this.RaiseEvent(nameChanged);
    }

    public void AdjustBooksSold(int count)
    {
        var booksSold = new BookSold(this.bookId, count);
        this.RaiseEvent(booksSold);
    }

    private void Apply(BookNameChanged nameChanged)
    {
        this.title = nameChanged.title;
    }

    private void Apply(BookSold bookSold)
    {
        this.numberSold += bookSold.count;
    }

    protected void RaiseEvent(object eventToRaise)
    {
        dynamic @ev = eventToRaise;
        Apply(@ev);
        this.eventsToCommit.Add(eventToRaise);
    }

    public ICollection<object> GetEvents()
    {
        return this.eventsToCommit;
    }

    public void ResetEvents()
    {
        this.eventsToCommit = new List<object>();
    }
}

Book repository

public class BookRepository
{
    IStoreEvents store;

    public BookRepository(IStoreEvents store)
    {
        this.store = store;
    }

    public void Put(Book book)
    {
        using (var stream = this.store.OpenStream(book.bookId, 0, int.MaxValue))
        {
            foreach (object o in book.GetEvents())
            {
                stream.Add(new EventMessage { Body = @o });
            }
            stream.CommitChanges(Guid.NewGuid());
            book.ResetEvents();
        }
    }

    public Book Get(Guid id)
    {
        using (var commits = this.store.OpenStream(id, 0, int.MaxValue))
        {
            var eventsToReply = commits.CommittedEvents;
            return new Book(id, eventsToReply);
        }
    }
}

Commands

public class BookNameChanged
{
    public readonly Guid id;
    public readonly string title;

    public BookNameChanged(Guid id, string bookName)
    {
        this.id = id;
        this.title = bookName;
    }
}

public class BookSold
{
    public readonly Guid id;
    public readonly int count;

    public BookSold(Guid id, int count)
    {
        this.id = id;
        this.count = count;
    }
}

Answer 1

Nice work for a first go. Depending on how you've wired up, fields, the fact that they hare readonly and lack of a parameterless public constructor are likely to cause issues with most serialization mechanisms - i.e. make them auto properties.

While I generally like to protect invariants by constraining stuff as you have, it's important to balance this with the fact that an event, once it has happened is fully baked - so a POCO with writable properties isnt as crazy as you'd think.

One other thing I'd do is get rid of the ids out of the events.

(And go join the DDD-CQRS mailing list - there's a recent discussion that touched on the notion of fat events - i.e. restating stuff that can be gleaned from previous events [on the basis that you know what an event handler needs to react to an event] which I agree is a bad idea).

I must post my AggregateBase - there's a of subtleties you got right but lots of litle things I'd change. Poke me in a week if I haven't done it sooner...