First things first, DDD and onion architecture are different things you can use one without the other. I almost always use onions, but almost never DDD... it is just overkill for most things in my opinion (and the opinion of its creator). Additionally, I feel their are other techniques that can be used instead of DDD, even in situations where it is useful.
The core of your onion (non-DDD) is your domain project. This contains business objects. They model the conceptual workings of your application, without regard for implementation details like persistence, or UI. There is no references to the database, or even classes that deal with the database!
Let's say your application is a proprietary tax application. The core of your onion, the business objects, would have classes like:
TaxCalculator, ect. They would reference each-other, but never anything to do with the UI or DB.
The next layer of the onion, infrastructure, would have your repositories to save and recall. This project will reference your domain objects. Your
IncomeEntryRepository will have methods like
GetIncomeEntries that return
Next, you have your UI Project on the outside of the onion. It can make use of both the business objects and the repositories to show useful information to the user.
Everyone has been happy with your fast and efficient UI, but now the C levels come to you and ask you to make an API for some of the subsidiaries. They wan't to leverage the power of your application, but legal codes mean they can't have access to your data. This is where the power of the onion.
Simply, on the outer edge of the onion, add a Web API that allows the subsidiaries to input their own data and run Tax calculations on them. This web api will only need to reference the domain core