If you don't use an ORM tool, then you have to do the ORM yourself. Unfortunately, ORM adds a high level of complexity. There are some strategies to deal with the challenges, which you've alluded to.
Include the Repository in the Domain Object
Pro: Allows for lazy loading. The domain model keeps the data manipulation pretty simple while letting the repository component do the persistence layer.
Con: You might cause multiple database calls in some cases where one would have been enough. It can be more difficult to use the database to do the filtering for you. That means increased memory usage, and object manipulation.
Serialize everything from the Repository
Pro: You are in full control of the persistence process without triggering later calls to the database. You can use the database to apply filters, etc. much more easily.
Con: Can be very expensive when all you need is a summary of data in a large list.
Something In-Between
Some lessons I've learned when designing an app around a NoSQL database made me think a bit differently about how I was separating the data. I know that for the time being that solution is off the table. However, some of the same strategies apply to DDD:
- Think about where the separation needs to be. I found that some light weight "reference" objects were great for supplying the summary information for lists, without getting everything from the children. Getting the parent and the reference child objects was pretty quick and let me populate the screen completely.
- Don't add anything you don't need until you need it. If you choose to get everything at once, and that starts slowing down the app, you can add the complexity of lazy loading then.
- Add tests as you go along.
DDD is both powerful and different from the current understanding of how to build applications. I find DDD favors environments where everything is in one layer like a desktop app. With web applications, you need to be able to serialize objects to and from JSON and have the screen react appropriately. The logic you painstakingly apply in the web application layer doesn't automatically convey to the web browser. I think that's why the anemic domain model is a bit more popular these days.
I will say that using a NoSQL database does solve a number of the woes surrounding the complexity that is ORM. If/when you can take a look at it, you'll see how it solves a number of the problems for you.