I'm getting my head around DDD and how to build up an C# Project structure for an .Net Core WebApp. I searched quite a bit around the web, for example How to structure a Domain Driven Design in an Onion Architecture?, https://github.com/zkavtaskin/Domain-Driven-Design-Example and several Pluralsight courses.
What bogs me is the fact, that this HelloWorld-examples don't seem to work very well in the real life: Let's say we build the propagated onion structure of Application, Domain and Infrastructure. Application would in this case be the WebApi-part, Domain the Domain-Services, Entities, Value Objects etc. and Infrastructure the implementation of the Interfaces defined in the Domain-Assembly.
So far so good, but with this approach, I'd need to define every bit of helping code in the Domain-Layer. For Services, Handlers, etc. I could define just the Interfaces and let the implementation inject from the Infrastructure-layer. But as soon as I started coding like this, I had folders like Attributes, Handlers (low level services for REST, Files etc.) and a ton of other technical stuff in my domain-layer. For the sake of testing, I tried to revert the dependency, so the Domain targets the Infrastructure. This allows to move all the supporting code and low-level handlers to the Infrastructure, but makes communication awkward: Since the entities and value objects are still in the Domain, the Infrastructure doesn't know them anymore, so I'd need to map them to DTOs, adding another mapping layer just for this communication.
From reading Eric Evans book, I took the idea, that the Domain-Layer should be written in the ubiquitous language, be technical agnostic and be the communcation platform with the domain experts. But I can't find a good solution to have the both of best worlds. Am I missing something crucial here?