CODEWITHSUNDEEP
c#.netdomain-driven-designcqrs
cs0815
cs0815

Reputation: 17388

persistence of domain model in cqrs

Looking at this test, which looks very familiar to me coming from a crud world (see also here):

[Test]
public void When_calling_Save_it_will_add_the_domain_events_to_the_domain_event_storage()
{
    var client = Client.CreateNew(new ClientName("New Client"), new Address("Street", "123", "5000", "Bergen"), new PhoneNumber("1234567890"));
    client.UpdatePhoneNumber(new PhoneNumber("1234567890"));
    client.UpdatePhoneNumber(new PhoneNumber("1234567890"));

    _repository.Add(client);
    _eventStoreUnitOfWork.Commit();

    Assert.That(_domainEventStorage.GetEventsSinceLastSnapShot(client.Id).Count(), Is.EqualTo(3));
    Assert.That(_domainEventStorage.GetAllEvents(client.Id).Count(), Is.EqualTo(3));
}

Should an entity/aggregate root/object ever be persisted like this? Should not everything be achieved via commands/the bus (e.g. the mvc controller/service should only have a reference to the bus not ever to repositories? Or is this just an isolated unit test as such?

Upvotes: 0

Views: 230

Answers (1)

Codescribler
Codescribler

Reputation: 2305

In general I agree that generating state via commands and events and coordinating those commands and events via some form of bus is a common approach in a CQRS system. It therefore makes sense to test the system in those terms, however, it appears to me that the thrust of this test is to ensure the event persistence mechanism is working and not that the 'client' produces the correct events given certain commands (although it does indirectly do a bit of that). Given the thrust of the test is to ensure the event persistence system works, it may be a bit clearer/more explicit to just pass events directly to the persistence system and ensure it does the right thing.

Upvotes: 1

Related Questions