For my application, I am looking at using an ORM and currently trying to decide if the domain layer should interface with it through a Data Access Object, Repositories, or something else? I am hesitant to pair an ORM with repositories because they can become redundant if the ORM entities are identical with the domain objects, but having one big DAO seems cludgy. I want to keep my SQL centralized, but I can't figure which of these options, if any, would make the most sense. Any suggestions on an appropriate design pattern?
This is very opinion-based, but I tend toward creating separate entities from my domain models. The domain model needs to closely match your domain, whereas your entities need to closely model your storage. They may initially match very closely, and seem really redundant, but they very often drift dramatically from each other very quickly.
That being said, wrappers that do nothing but map domain entities to persistence entities often feels horrible, and a giant waste of time. Additionally, it doesn't pay off until much later in the game, when you are doing refactoring, and you realize that your domain isn't quite right, but you don't want to modify your persistence layer.
The good news is, most languages/frameworks have some form of a mapping library that will let you automatically map from one object to another that is similarly structured. This is a great way to speed this up initially, while still giving yourself flexibility to create a manual mapping when the requirements change out from under you.