Is the structure of the project correct?

Using Django Getting Started
1

Here is the structure of my project:

├─── applications
│ ├─── about
│ │ ├─── admin.py
│ │ ├─── api
│ │ │ │ └─── __init__.py
│ │ │ ├─── apps.py
│ │ ├──── __init__.py
│ │ ├─── libs
│ │ │ │ └─── __init__.py
│ │ │ ├─── migrations
│ │ │ │ └─── __init__.py
│ │ ├─── models.py
│ │ │ ├─── services
│ │ │ │ └─── __init__.py
│ │ ├─── templates
│ │ ├─── tests.py
│ │ │ └─── views.py
│ ├─── account
│ │ │ ├─── admin.py
│ │ ├─── api
│ │ │ │ └─── __init__.py
│ │ │ ├─── apps.py
│ │ ├──── __init__.py
│ │ ├─── libs
│ │ │ │ └─── __init__.py
│ │ │ ├─── migrations
│ │ │ │ └─── __init__.py
│ │ ├─── models.py
│ │ │ ├─── services
│ │ │ │ └─── __init__.py
│ │ ├─── templates
│ │ ├─── tests.py
│ │ │ └─── views.py
│ ├─── blog
│ │ │ ├─── admin.py
│ │ ├─── api
│ │ │ │ └─── __init__.py
│ │ │ ├─── apps.py
│ │ ├──── __init__.py
│ │ ├─── libs
│ │ │ │ └─── __init__.py
│ │ │ ├─── migrations
│ │ │ │ └─── __init__.py
│ │ ├─── models.py
│ │ │ ├─── services
│ │ │ │ └─── __init__.py
│ │ ├─── templates
│ │ ├─── tests.py
│ │ │ └─── views.py
│ ├─── middlware
│ ├─── order
│ │ ├─── admin.py
│ │ ├─── api
│ │ │ │ └─── __init__.py
│ │ │ ├─── apps.py
│ │ ├──── __init__.py
│ │ ├─── libs
│ │ │ │ └─── __init__.py
│ │ │ ├─── migrations
│ │ │ │ └─── __init__.py
│ │ ├─── models.py
│ │ │ ├─── services
│ │ │ │ └─── __init__.py
│ │ ├─── templates
│ │ ├─── tests.py
│ │ │ └─── views.py
│ └─── product
│ ├─── admin.py
│ ├─── api
│ │ │ └─── __init__.py
│ ├─── apps.py
│ ├─── __init__.py
│ ├─── libs
│ │ │ └─── __init__.py
│ ├─── migrations
│ │ │ └─── __init__.py
│ ├─── models.py
│ ├─── services
│ │ │ └─── __init__.py
│ ├─── templates
│ ├─── tests.py
│ └─── views.py
├─── configs
│ ├─── asgi.py
│ ├─── __init__.py
│ ├─── settings.py
│ ├├─── urls.py
│ └─── wsgi.py
└─── manage.py

configs - project settings
applications - apps:)
middleware - middleware:)
application/app/libs - python libraries (I think it's better to use the standard interface for python libraries and add them to site-packages, even if they are written by me)
application/app/api - third-party api (I think it's better to put the api on the top level)
application/app/templates - templates 
application/app/services + models.py - business logic
application/app/views.py - views

What is better to change and is this structure “good” for an average team?

P.S I’m also wondering how the interaction between django applications should be handled if, for example, order uses models from account and product (I got the idea to put a reference to models in settings like AUTH_USER_MODEL).

I’ve read many articles about effective patterns for building web applications in django, but I haven’t figured out the best way to go about it

2

If you’re coming to Django from other frameworks, I’ll start out by saying Django is different. If those other frameworks were not Python-based, Python is different. A lot of what you may have previously learned from structuring projects for other frameworks and languages is not particularly useful with Django.

<opinion>
Personally, I think you’ve way overcomplicated this as a starting point.

Unless, and until, you’ve reached a point where this type of organization becomes necessary, and, you understand why, and you’re prepared to handle the issues encountered by doing something like this, I would encourage you to adhere to the standard Django conventions.

e.g.:

project/
├─ project/ # Can be renamed to anything desired
   ├─ wsgi.py
   ├─ asgi.py
   ├─ urls.py
   ├─ settings.py
   ├─ fixtures/
├─ app1/
   ├─ models.py
   ├─ views.py
   ├─ urls.py
   ├─ forms.py
   ├─ admin.py
   ├─ templates/
      ├─ app1/
   ├─ management/
      ├─ commands/
   ├─ static/
      ├─ app1/
├─ static/
├─ templates/

And, if the project gets large enough, the directory structure for app1 can be replicated for an app2 and possibly more.
</opinion>

I’ve been using Django regularly for 10 years, and have deployed more than 20 production instances of different projects. I can only think of 3 of them where it has been necessary or desirable to create them as more than 1 app. Also, I’ve never encountered a situation where it has been desirable to use anything other than the standard Django project layout.

Don’t make things harder for yourself. Don’t add unnecessary complexity. Issues like this:

simply don’t exist if they’re all part of the same application.

For some other perspectives on this topic, see:

Note, a couple of these are quite lengthy. I would encourage you to read them through in their entirety.

3

Thanks, I’ve read almost all of the links you’ve provided, but I’m just getting more confusion in my head because of the different points of view and I don’t understand how best to proceed. I understand on the one hand that excessive work on architecture is not necessary for small projects, but my perfectionism does not allow me otherwise, because I want to make everything I touch scalable and readable for others. About my project, I would like to make it as perfect as possible in terms of architecture, as I will add it to my portfolio so that employers will give me a plus for it in the future. So, it is not clear to me what problems with my structure can happen in the future and how best to deal with it. Also, I’ve heard many times how the service layer is criticized, but it seems to me that this is a better solution than shoving some logic not related to the model data into models.py and leaving the logic of the view layer in views.py, and sending the business logic not related to the data to service, please tell me why this solution is bad?
Now after your answer and other articles I came to the structure below, it seems to me the most optimal, but I would like to know your opinion:

.
├── configs
│   ├── asgi.py
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-310.pyc
│   │   ├── settings.cpython-310.pyc
│   │   ├── urls.cpython-310.pyc
│   │   └── wsgi.cpython-310.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── furbar
│   ├── api
│   ├── apps.py
│   ├── libs
│   ├── models
│   │   ├── about.py
│   │   ├── account.py
│   │   ├── blog.py
│   │   ├── order.py
│   │   └── product.py
│   ├── services
│   │   ├── about.py
│   │   ├── account.py
│   │   ├── blog.py
│   │   ├── order.py
│   │   └── product.py
│   ├── static
│   ├── templates
│   ├── urls.py
│   └── views
│       ├── about.py
│       ├── account.py
│       ├── blog.py
│       ├── order.py
│       └── product.py
└── manage.py
4

Because it creates needless complexity.

You need to “unlearn” whatever code organization and architectural design practices you’ve learned from other frameworks and languages. Python is not Java, PHP, or any other language. Django is not Spring, Laravel, etc, etc.

Then adhere to Django’s structural standards and best practices. Do not borrow concepts and ideas from other environments that don’t provide value here.

Speaking as a senior developer who has been involved in the hiring and employee evaluation process for more than 20 years, I can tell you that seeing a portfolio containing a project architected like this would go immediately into the Reject pile, because it demonstrates a lack of understanding of Django and Python.

Not from my perspective. You’re still needlessly creating complexity.

Simple is better, until you reach the point where you must make changes to adapt to changing requirements.

5

I understand you, apparently my ideas about how the code should be structured are ineffective here. Then I wonder how to organise, you above discounted showed me: views + models (add here only the logic associated with its model) - business logic, templates - representation, the controller is left to Django. I’m wondering, won’t it be difficult to navigate in the code, which will be in one file? Couldn’t it be divided at least into several views, dealing with their own full-fledged task. I also wonder where to put the code to interact with the api (I assume you will say views, but again - won’t it be difficult in the future if everything is in one heap?). About the models, can they also be divided into modules to make it easier, again, to navigate? You say that what I’m proposing is wrong, but I don’t understand how complexity is created in structures like mine. Also, you said it doesn’t fit the ideology of django and python, but what is that “ideology”, could you drop me a link to an article or something? Thank you so much for your help! Below is the structure I came to after discussing with you, let me know if this structure is bad too)

.
├── configs
│   ├── asgi.py
│   ├── __init__.py
│   ├── __pycache__
│   │   ├── __init__.cpython-310.pyc
│   │   ├── settings.cpython-310.pyc
│   │   ├── urls.cpython-310.pyc
│   │   └── wsgi.cpython-310.pyc
│   ├── settings.py
│   ├── urls.py
│   └── wsgi.py
├── furbar
│   ├── apps.py
│   ├── models
│   │   ├── articles.py
│   │   ├── orders.py
│   │   ├── products.py
│   │   └── user.py
│   ├── static
│   ├── templates
│   ├── urls.py
│   └── views
│       ├── about.py
│       ├── account.py
│       ├── blog.py
│       ├── order.py
│       └── product.py
└── manage.py
6

Not at all. In fact, our experience has been exactly the opposite.

See the discussions here: categorizing models in own files instead of models.py and How to separate models.py into django app by folders & sub-folders?

For a discussion from the opposite perspective, see Combining Urls, Views, Forms, and Models into fewer files

“Code to interact with the api” - I’m assuming by “api”, you mean a REST-style HTTP interface accessible to the outside world. If so, keep in mind that your api are views. If code receives an HTTP request and returns a response, it is, by definition, a view.

By having one more set of “entities” that you need to understand and manage. You’re (needlessly) adding more information that needs to be remembered and understood. You’re adding another decision into the development process that doesn’t need to be there.

The entire Django documentation. The Django tutorial. The Django Girls tutorial. The fact that the Django docs themselves don’t address these issues - and some of the side effects involved with them - is itself an indication that the developers of Django don’t consider them necessary.

Sorry, that’s still too much from my perspective. You will never convince me that there is value in separating out individal models or views to that degree of granularity. I’ve got too much history dealing with systems consisting of thousands of files to ever want to go back to a situation like that. It’s just not worth it.

1 Like