It’s not uncommon for new Django developers to become understandably confused by Django’s usage of the word “app.” So before we get into Django app design, it’s very important that we go over some de nitions.
A Django project is a web application powered by the Django web framework.
Django apps are small libraries designed to represent a single aspect of a project. A Django project is made up of many Django apps. Some of those apps are internal to the project and will never be reused; others are third-party Django packages.
ird-party Django packages are simply pluggable, reusable Django apps that have been packaged with the Python packaging tools. We’ll begin coverage of them inchapter 17,Django’s Secret Sauce: ird-Party Packages.
4.1 The Golden Rule of Django App Design
James Bennett serves as both a Django core developer and its release manager. He taught us every-thing we know about good Django app design. We quote him:
“ e art of creating and maintaining a good Django app is that it should follow the truncated Unix philosophy according to Douglas McIlroy: ‘Write programs that do one thing and do it well.”’
In essence,each app should be tightly focused on its task. If an app can’t be explained in a single sentence of moderate length, or you need to say ‘and’ more than once, it probably means the app is too big and should be broken up.
Chapter 4: Fundamentals of Django App Design
4.1.1 A Practical Example of Apps in a Project
Imagine that we’re creating a web application for our ctional ice cream shop called “Two Scoops.”
Picture us getting ready to open the shop: polishing the countertops, making the rst batches of ice cream, and building the website for our shop.
We’d call the Django project for our shop’s websitetwoscoops project. e apps within our Django project might be something like:
ä A avorsapp to track all of our ice cream avors and list them on our website.
ä Ablogapp for the official Two Scoops blog.
ä Aneventsapp to display listings of our shop’s events on our website: events such as Strawberry Sundae Sundays and Fudgy First Fridays.
Each one of these apps does one particular thing. Yes, the apps relate to each other, and you could imagineeventsorblogposts that are centered around certain ice cream avors, but it’s much better to have three specialized apps than one app that does everything.
In the future, we might extend the site with apps like:
ä Ashopapp to allow us to sell pints by mail order.
ä Aticketsapp, which would handle ticket sales for premium all-you-can-eat ice cream fests.
Notice how events are kept separate from ticket sales. Rather than expanding theeventsapp to sell tickets, we create a separateticketsapp because most events don’t require tickets, and because event calendars and ticket sales have the potential to contain complex logic as the site grows.
Eventually, we hope to use theticketsapp to sell tickets to Icecreamlandia, the ice cream theme park lled with thrill rides that we’ve always wanted to open.
Did we say that this was a ctional example? Ahem...well, here’s an early concept map of what we envision for Icecreamlandia:
4.2: What to Name Your Django Apps
Figure 4.1: Our vision for Icecreamlandia.
4.2 What to Name Your Django Apps
Everyone has their own conventions, and some people like to use really colorful names. We like to use naming systems that are dull, boring, and obvious. In fact, we advocate doing the following:
When possible keep to single word names like avors,animals,blog,polls,dreams,estimates, and nances. A good, obvious app name makes the project easier to maintain.
As a general rule, the app’s name should be a plural version of the app’s main model, but there are many good exceptions to this rule, blog being one of the most common ones.
Don’t just consider the app’s main model, though. You should also consider how you want your URLs to appear when choosing a name. If you want your site’s blog to appear at http://www.example.com/weblog/, then consider naming your app weblog rather thanblog, posts, orblogposts, even if the main model isPost, to make it easier for you to see which app corre-sponds with which part of the site.
Use valid, PEP 8-compliant, importable Python package names: short, all-lowercase names with-out numbers, dashes, periods, spaces, or special characters. If needed for readability, you can use underscores to separate words, although the use of underscores is discouraged.
Chapter 4: Fundamentals of Django App Design
4.3 When in Doubt, Keep Apps Small
Don’t worry too hard about getting app design perfect. It’s an art, not a science. Sometimes you have to rewrite them or break them up. at’s okay.
Try and keep your apps small. Remember, it’s better to have many small apps than to have a few giant apps.
4.4 Summary
is chapter covered the art of Django app design. Speci cally, each Django app should be tightly-focused on its own task, possess a simple, easy-to-remember name. If an app seems too complex, it should be broken up into smaller apps. Getting app design takes practice and effort, but it’s well worth the effort.