How to correctly design the structure of the application?

Question

PHP

It has the following structure:
The application has the following entities:

• Car (base of cars, their parameters, etc.)
  
• Comment
  
• Geo
  
  • Region
    
  • District
    
  • City
    
  
  
• Product
  
• Sale
  
• User
  
  • Vehicle owned by the user
    
    • Car driver
      
    
    
  
  

Questions:
1. Entities - application entities. Am I using this term correctly?
2. Each entity will contain (if necessary) the implementation of the repository, service, business model (DTO), ActiveRecord (for example, for links) - is it "ok" or do you need to somehow organize the infrastructure for each entity differently?
3. Is this approach suitable for encapsulating business logic in a separate layer?

Answer 1

oh, you are trying to build something that is not understandable. Judging by the question, you have a set of patterns and not an architecture. What do you want to get as a result? layered architecture? so it's not built like that. DTO is an object for data transfer, it does not store business logic, the repository and Active Record are usually not shared. In general, judging from the statement of the problem, I can say that you do not quite understand how to build such an architecture, so I recommend that you first read about layered architecture (for example, from the same Fowler), about the domain model, about DDD, and then move on to practice. To get started, you can go over these articles to begin with:
article 1
article 2
article 3
article 4

Answer 2

We can only say that the semantics of the folders is correct (daddy is nested in another daddy correctly)
And what more can I say?
It is much more important that you follow the standards of the framework, properly distribute logic between models, make a thin controller, etc.
Usually the logic is dictated by the relational database, if you use it.
Correctly build the database, everything will line up by itself and in the code.

Answer 3

At a minimum, it is worth renaming the same car entities. Either create a caruser for a car user, or cardata (carinfo) for car information.