I am learning DDD and I am a little bit lost in Infrastructure layer.
As I understand, \"all good DDD applications\" should have 4 layers: Presentation, Application, Dom
Sticking with DDD definitions, a Repository is different than a Service. A Repository directly correlates to an Entity, often an Aggregate Root. A Service defines behaviors that don't really belong to a single Entity in your domain. You can absolutely find Services in every layer, though the types of problems they address differ from layer to layer and may be different from DDD's conceptual Service.
When working at the conceptual level, a DDD Repository differs from a DDD service in that it is specifically tied to Entity persistence. A Service can address any Domain, Application, or Infrastructure problem you may have.
You run into terminology clashes with DDD all over the place. For instance, a DDD Repository is NOT the same thing as the Repository pattern found in Martin Fowler's PoEAA book, though it may employ such a pattern. This is often a source of confusion for many people.
It helps with DDD if you always keep the Domain Model at the very center of everything you do. When it comes to layering DDD apps, I often choose Jeffrey Palermo's Onion Architecture. Check it out. Download CodeCampServer, an example app using this architecture. I think it's a perfect fit for DDD programming.
Good luck!