DDD. Layers, Persistence Ignorance. What where?

Question

.NET

Good day.
I've been trying for several months to understand the DDD philosophy and I can't :)
Now I have 5 layers - infrastructure, domain, application, data access layer, web.
There is an implementation of the UnitOfWork, Repository, Specification patterns in the Data Access Layer. Their interfaces are in the infrastructure.
1. And here's the question, where do I select and save data, in which layer?
2. Should the Domain layer be aware of the repository/unit of work interface?
3. Should all DAL usage logic (UoW, repository...) be in the Application layer?
4. Where should the data sampling conditions (specification) be located?
5. If you need to write any value to the database during the execution of business logic (calling 1 method from the Domain layer, while the value for writing exists between the beginning and end of the method execution, but not before and not after), then how to make such a record in DB?
I do not rule out that I give an example of some specific architecture, which I consider de facto for DDD. But judging by all these smart books, these are the layers that should exist in a DDD application.
I read books, looked at a lot of code on github, looked at a lot of answers on stackoverflow, but nothing in my code is connected.
Therefore, I decided to open the issue for a more open communication. Thank you for your attention.

Answer 1

For the answer has not been found, I will continue the monologue.
Another good solution was to store interfaces for repositories.
These interfaces should have methods such as GetLastUser, GetRockMusic()… Based on the Repository and Specification patterns, such methods will contain 1-2 lines of implementation, which is very, very convenient. And useful in query optimization.
After some time since I asked the question, I had the opportunity to read more books and articles.
Now, when I read my own questions, I begin to understand their vagueness, sometimes incorrectness.
So, if you are asking the same questions about the same topic, just dig more globally, you will definitely find another path.
Better yet, find a DDD practitioner and learn from him :)

Answer 2

Going through all sorts of combinations of words in Google, I found primary answers to my own questions:
1. We do all manipulations with the database using Repository / UnitOfWork in the Application layer.
2. No. For Persistence Ignorance
3. Yes.
4. There are 2 types of specifications - Business and DB. Business logic specifications are stored in the Domain layer. There are also specifications for specific ORMs/DBs, but I can't find a concrete example right now.
5. Business logic should be designed in such a way that such situations would not arise. But if you still need it, then you can implement
Domain Events. We create them inside the domain, subscribe to them in the Application layer, and set them on fire during the execution of some business process.
And Domain knows nothing about loggers/db/etc and the task is executed.
Of the minuses, one can consider errors that are unforeseen for the business logic during the execution of event handlers. But even here I think you can get rid of the problem at the Application layer level.
And yet, questions remain about how to select data from the database during the execution of a business process. This is where things get easier if you understand and use Aggregation Root.
It all sounds good enough, but now the next question is what is the Application layer, what does it do and what does it not do?
Is the statement "Application layer provides use cases for business logic in the context of this application" correct? “
Naturally, all conclusions are not supported by extensive experience, since everything was obtained in hasty experiments.
Therefore, I look forward to criticism, discussion and reflection.