Hacker News new | past | comments | ask | show | jobs | submit login

As described by the documentation, Django applications are “a Python package that provides some set of features”, reusable, and are “a combination of models, views, templates, …, URLs, etc”. What this approach describes is not standard at all to the Django app structure. Some cons to this include: no ability to make new versions of an app and use them concurrently, removing set standards and confusing ANY new engineer that must work on the project, no compartmentalization of business logic, etc etc. There is a reason why Django is structured the way it is. Removing the battle tested skeleton may mean it is not the web framework for your particular project.

For a detailed explanation of what Django app's are and why they are structured the way they are please refer to the `2. Intro to Django Applications` section of https://medium.com/@djstein/modern-django-part-2-rest-apis-a...

For any new Django engineers reading this, I would point you towards https://github.com/pydanny/cookiecutter-django for the best / most complete structure.




> no compartmentalization of business logic, etc etc

The proposed design does compartmentalize business logic; it's all in the `domain` package, divided by business application/use-case. This looks to be to be inspired by the DDD approach.

> no ability to make new versions of an app and use them concurrently

Anecdotal, but I've never required this in my monolithic web app (6 developers), and I don't foresee requiring it any time soon.

> Removing the battle tested skeleton may mean it is not the web framework for your particular project.

This is a bit dogmatic for my taste; Django is just a tool. If the default layout works for you, great. When your project outgrows that default, change it. (But I'd advise being sure that you really have outgrown the defaults before doing so).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: