In what cases it is worth resorting to the use of architectural approaches?

Question

Software design

Briefly : in what cases can one do without splitting the application into layers and following Clean Architecture, DDD, etc., and in what cases is it better to do everything according to the rules?
Let's say there is a task to develop a REST API. There will be 12 entities in the application. There are no complex business rules. Basically only CRUD operations are needed. Sometimes, before performing any operation, you need to check the user's access rights to a specific object (for example, a comment). Is it worth splitting applications into layers, following Clean Architecture or DDD, etc.? Or push all the code into one project, use the Entity Framework to work with the database, map the EF entities to the API resource model, and return them to the user? All logic will be in the controllers.

Answer 1

I am sure at the beginning you need to do it as simply as possible, as primitive as possible and only GRADUALLY develop the product, and only THERE where it is needed.
In no case should you engage in overengineering, perhaps at the next iteration, in general, half of the functionality will be thrown out and you will develop in a completely different direction, and even if not thrown out, you will revise the data model itself, interaction schemes, etc.
Such things should gradually be born in response to your needs. No need to introduce approaches or technologies (some layers) just to implement. You need to accurately answer the question WHY, and WHY you are implementing it, while there are no answers to these questions, then such an approach or technology is not needed.
Accordingly, if you ask whether you need to do this -> the answer is definitely no. Until you yourself grow up to understand where and why this should be done.

Answer 2

Splitting facilitates further upgrades (maintenance).
If you immediately mentally see the project in its entirety with all the details at once and you know that it will always be in this form, you can not break it.
If you want to save on development now, if you don’t want to strain your brain now, and you don’t give a damn about what will happen to the project later, you don’t have to break it.
If you do not want to test automatically, in parts. If you are so self-confident or think that superficial tests will be enough - you can not break it.
In principle, all these principles are often ignored, and projects still somehow live. And even for years. These are not critical requirements. Just gives further convenience. At the cost of a large investment of time at the beginning of the project.