Django Project Architecture: The best project skeleton ever.

Over 7 years of experience in Django web development, I always try to find out the simple and the best Django project structure. The quintessence of my experience, knowledge, and research inspired me to write this and create one structure that not only helps a micro project but also the extensive Django projects.

Let’s show you the unique structure of the Django project.

The above figure is a mixture of conventional and extraordinary software architectural patterns. We, as a software industry always ready to adopt new things and this is my effort toward this. I also know this after a few years ago this architectural design may change and we all have to adopt that as well.

I assume that you know the purpose of the files which we used in typical Django project architecture e.g. urls.py, models.py, and so on. Hereinafter, I am going to explain the usage of files that are unconventional in use and those are mainly services.py and factories.py, and also describe how it is different from views.py.

In this architecture, we normally use views to write business logic and bind it with URLs. ( Bonus Tip: You should map main URLs with the app name ( under the modules, while URLs under the app folder should have a unique name)

You should write your views ( define in views.py ) as short as you can for better programming. In actual development, we have to deal with complex business logic which required more lines of code. In addition, it might be required to implement the same business logic multiple times, but we also take care of the “DRY” (Don’t Repeat Yourself) principle. In this case, we use our “services.py”

In services.py, we write the actual business logic or supporting functions. This function may or may not repeat multiple times in the apps but we put in services.py file to create our code simple and easy to debug or understand. Furthermore, every developer should write the code modular-based, so it also helps to split code in a module.

In a rapidly growing era, we are not capable to predict the future changes in the business as well as our software design. Our client always wants to change at any level hence it’s required to use the law of Demeter (divide responsibilities between classes and loose-coupling by eliminating the need to bind application-specific classes into the code). In this case, we use our “factories.py”

In factories.py, allows the sub-classes to choose the type of objects to create. It divides the responsibilities of classes and makes loosely coupled. Due to this, at any point in time, we can adapt to the changes and implement them quickly.

I am grateful to all of you to give your precious time to read this article. In my next blog, I will share “The best way to implement Factory Method design patterns” under the series — The best…..

Keep reading Keep Learning.

Thanks for reading.