In DDD, how can repositories be optional?

The question (and title) is steeped in a general conflation of different concepts such as DDD, CQRS and the repository pattern, and implied statements that they are mutually exclusive or that they are different solutions to the same problem.

None of that is the case. These three concepts all act on a different scope, and can be implemented (or not) without that therefore requiring/excluding the implementation of the others.

Command handlers should be in the application service layer, correct?

There's nothing in the definition of CQRS that dictates that this is an application layer implementation. CQRS dictates that you split your logic across individual handlers (as opposed to e.g. bundling them in a single service interface).

However, one can implement this kind of separation in any layer they want to. This could be implemented on the Application layer (and to be fair it commonly is), but it could just as well be implemented on the Persistence layer.

There's no conclusive answer here, other than "no, it's not inherently about the Application layer".

I don't understand how can using CQRS mean we don't need repositories anymore.

Generally speaking (observe that I'm going to address fringe definitions in a moment), repositories are thought of as the same kind of service interface that bundles all of the interactions (commands, queries) related to a particular data store (commonly scopes to a particular database table), just like I described before. Using this interpretation, one could inherently imply that repositories are at odds with CQRS in the sense that repositories bundle the operations whereas CQRS inherently prescribes their separation.

However, there is wiggle room in all of these definition and interpretations.

For example, one could separate their classic repository into a read repository and a write repository. The queries are then not individually separate (neither are the commands), but the queries are separated from the commands and this sufficiently satisfies the definition of CQRS.

Another thing to point out might be that the CQRS separation might only be enforced on the interface level, i.e. the application talks to the persistence layer using individually decouples query/command objects/interfaces. But in the actual implementation of the persistence layer, there might still be a single repository that implements multiple of these interfaces/handlers.

This can make sense in cases where you want to have some reusability (I'm thinking of e.g. a reusable repository mock for testing purposes), or if you want your overall codebase to already be CQRS-compatible even though you haven't actually separated your read and write stores themselves just yet. Not a common scenario but one I have concretely encountered.

You'll notice that I haven't yet brought up DDD, and there's no reason to do so. DDD is completely unrelated to this alleged conflict between CQRS and repositories. Sure, in a DDD context your specific syntax is going to look a bit different, but its inclusion (or lack thereof) doesn't impact the general considerations that this answer touched on.

The main point here is that depending on your specific definition of CQRS and repositories, they could be interpreted as being polar opposites or not. So you could be right, as could the person who you are quoting and seemingly disagreeing with.

1. The quote is precisely about Bogard breaking the persistence-unawareness rule, willing to embrace some amount of coupling with his persistence technology/framework for the sake of simplicity and flexibility. ORMs usually already provide data objects that look like repositories anyway. His application services (or even controllers) will call these objects directly, without a data access abstraction layer.

So I’m over Repositories, and definitely over abstracting your data layer, but where does that leave us? I don’t think creating an abstraction over your ORM provides much value

https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/

i dont use a repository with EF because it already implements the pattern (as well as the identity map pattern)

but i do with MongoDB because its client does not implement either

https://twitter.com/jbogard/status/1188810487364030464?lang=en

2. As for going CQRS meant that we didn't really have a need for repositories any more, it seems that his gripes are more with Aggregates than Repositories per se.

One part of it is that Aggregates are no longer a valid unit of data on the read side in a CQRS world where you want ad-hoc queries. Something that I personally always thought went without saying, and didn't necessarily mean you couldn't have Repositories on the write side and something else on the read side. But I guess in the late 2000s things were a lot more blurry and it was not a granted.

On virtually every screen our application, we show the exact same entity. That’s around 150 screens or so, where what you see begins with one Person, and filters down from there. This made things quite interesting from the query optimization standpoint. We had two choices – go through the root Person entity to all of its children, in one slice. Or, go from the children, and get back to the parent. But sometimes we show bits and pieces of various slices of our Person object, things that did not fit well with just one Repository call.

On the write side, his problem is with implementing complex persistence logic in repositories that could be easily replaced with ORM cascades. Something that I cannot speak to since I never encountered the need to model commands spanning multiple aggregates in a lot of slightly different ways for each screen.

Thus it started to become confusing how we should handle cascades and save logic. Since boundaries varied screen-to-screen, it became obvious that any custom save logic in a Repository could be handled perfectly well in the ORM layer, with cascades. Eventually, our model became extremely connected, with appropriate cascading and modification operations available only when specifically needed.

https://lostechies.com/jimmybogard/2009/09/11/wither-the-repository/ (hard to find because "CQS" is used in place of "CQRS" there)