How to stop doubting in which daddy to put the class and so on?

Question

Programming

Good afternoon, I noticed that my main problem, which eats up a lot of time, is reflection and eternal thought about how to name the class and in which daddy it is correct to put it, whether it can be duplicated, etc.

For example, I have DTO, Entity, they essentially duplicate each other, only Entity contains / can contain some basic logic, DTO - only write / read logic.

But they duplicate each other, which at first glance is not very good, but if you think about it, it's right.
And now the task appears, where you need to describe the object http.Response, whether it is possible to use DTO or whether you need to use Entity, or something else is needed, and in which folders to put it, and whether it will be correct, etc.

In general, this gives rise to a bunch of questions that cannot be answered unambiguously, but I want everything to be correct, structured to comply with DRY, and so on.

How to stop thinking for a long time and doubting the names of variables, classes, functions, files, locations, architectures, etc.?

Answer 1

In general, thinking and doubting is quite useful. But.
If this has already become a problem: ask yourself the question, where has this already helped me? In a previous project? How did I do it there? What and where did you put it? Does it hurt now? If not - reuse your approach . Ok, this seems to solve the problem with the question of what and where to put.
Now with names - name the class most obviously. What's on your mind now? ResponseDTO? Ok, great start. Realized the next day that this class would be better called ServerResponseDTO? Fine! There is such a feature: Refactoring, supported by almost all IDEs, and certainly supported by the usual renaming - well, you spent a couple of minutes on it, but did it get better? OK, in the next project, similar names will already "pop up" themselves - this will be your experience.