CODEWITHSUNDEEP
repositorydomain-driven-designaggregateroot
foresightyj
foresightyj

Reputation: 2106

In DDD, are repositories the only type of classes which can touch persistence?

In DDD, aggregate roots are persisted via repositories. But are repositories the only classes that can touch persistence in a bounded context?

I am using CQRS along side DDD. In the query side, things like view count, upvotes, these things need to be persisted but I feel it is awkward to model them as aggregate roots. I am limiting DDD aggregate root modeling to the command side. The query side is not allowed to use repositories. But often query side asks for small amount of persistence capabilities.

Also, I am using domain events, certain domain events also need to be persisted. I need something called event storage, but I only heard such terms appear in event sourcing (ES) and I am not using ES.

If such persistent classes are indeed needed. How do I call them, which layer should they belong to?

[Update]

When I read answers below, I realized my question is a bit ambiguous. By touch, I mainly mean write (and also including read).

Thanks.

Upvotes: 2

Views: 735

Answers (2)

guillaume31
guillaume31

Reputation: 14064

In the query side, things like view count, upvotes, these things need to be persisted

Not necessarily. CQRS doesn't specify

  • whether the read model should be materialized in its own database
  • how the read model is updated

The simplest CQRS implementation is one where the query side and command side use the same tables. The persistent source for Read Models could also be SQL (materialized) views based on these tables. If you do have a separate database for reads, it can be kept up-to-date by additional Command Handlers or sub-handlers or Event Handlers that operate after the command has been executed.

You can see a minimalist - yet perfectly CQRS compliant - implementation here : https://github.com/gregoryyoung/m-r/tree/master/SimpleCQRS

But are repositories the only classes that can touch persistence in a bounded context?

No, in a CQRS context, Read Model Facades (a.k.a. read side repos) can also read from it and your read model update mechanism write to it.

Also, I am using domain events, certain domain events also need to be persisted. I need something called event storage, but I only heard such terms appear in event sourcing (ES) and I am not using ES.

Event stores are the main storage technology of event-sourced systems. You could use them to store a few domain events on the side in a non-ES application, but they may be overkill and too complex for the task. It depends if you need all the guarantees they offer in terms of delivery, consistency, concurrency/versioning, etc. Otherwise, a regular RDBMS or NoSQL store can do the trick.

Upvotes: 3

Kaidjin
Kaidjin

Reputation: 1513

First, you need to think about your object model independantly of how you will store it in the database. You're designing an object model. Forget about the database for a moment.

You're saying that you don't want view counts or upvotes to be aggregate roots. That means you want to put them in an aggregate with some other objects. One of those objects is the aggregate root.

Without knowing more about your model, it's hard to say what you could do with more details, but the basic way would be to persist the aggregate root with the corresponding repository. The repository is not only responsible of storing the aggregate root, but the entire aggregate, following the relationships.

Think about the other side, when you are using the repository to retrieve an entity. You get an instance of your aggregate root, but if you follow the relationships, you also have all those other objects. It's perfectly logical that when you save an entity, all those other objects are saved too.

I don't know which technology you're using, but you should write your repository so that it does that.

also, why is the query side not allowed to use repositories ? Repositories are not only used to save data. They are also used to retrieve it. How are you retrieving objects without repositories (even if you don't modify them ?)

Upvotes: 1

Related Questions