Django App Design

Django를 사용하다보면 Django에서의 ‘App’이라는 개념에 혼동이 생기기 쉽다.(우리가 흔히 생각하는 모바일에서의 그 App이 아니기 때문이다.)

App Design을 이야기하기 전에 용어정리부터 하자면..

A Django project
Django로 만들어진 web application
Django Apps
Django project의 single aspect를 나타내기 위한 libraries. Django project는 많은 App으로 이루어져 있고 프로젝트에 속하며, 다른 project에서 재사용 되지 않는다.
INSTALLED_APPS
Django project에서 사용할 Django Apps들의 목록. settings.py에서 추가하거나 제거 할 수 있다.
Third-party Django packages
재사용 할 수있고, 어떤 프로젝트던 접목가능한 Django apps를 뜻함. Package로 배포된다.

간단히 예를들어 Django project는 냉장고로 생각해보자.
냉장고 안에는 반찬이나, 과일을 담을 수 있는 보관용기가 있어야 한다. 이 보관용기가 App이다.
또 Packages는 똑같은 보관용기이긴 하지만 냉장고 안에 있는 것이 아닌 편의점에 비치되어있고, 누구나 가져다 쓸 수있는 상태라고 생각하면 된다.


The Golden Rule of Django App Design

Django의 핵심 개발자는 좋은 App Design에 대해 이렇게 말했다.

“The 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"

이 분이 말한 것 처럼 각각의 App들은 그 역할에 촛점이 맞게 설계해야한다. 만약 각각의 앱의 역할을 한 문장으로 정의하지 못한다면, 그 App은 넓은 aspect를 커버하고 있는 것이며 잘게 쪼개야한다.


A Practice Example of Apps in a Project

만약 밴드 공연을 위한 Web을 만든다고 생각해보자.

먼저 Django Project를 만들어야한다. 그 속에는 이와 같은 App이 있을 것이다:

  1. Band : 밴드의 리스트가 있어야하며, 그 밴드에 대한 간단한 소개글이 있어야한다.
  2. Blog : 웹사이트를 위한 공식적인 게시판이 존재해야한다.
  3. Event : 각각의 공연에 대한 리스트가 보여져야한다.

현재 각각의 App들은 특수한 하나의 일을 하기위해 설계되어져있다. 이 앱들은 Event을 중심으로 연계되어 있지만 앞서 말했듯 하나의 거대한 App보다는 세분화된 세개의 앱이 더 좋다.

이 Web이 더 커지게 된다면 더 많은 앱이 더 필요할 수도 있다 :

  1. Shop : 메일이나, 기타 다른 방법으로 표를 팔 수 있어야한다.
  2. Ticket : 티켓을 각각의 공연에 맞게 세분화 해 팔아야한다.

이 App들 또한 Event App과 연계되어 있지만 각각의 기능들이 있으므로 새로 만드는 것이 좋다. Ticket App을 Event App에서 구현하는게 아닌 따로 떼어서 만드는 이유는, 많은 공연들이 꼭 유료가 아닐 수도 있거니와, Web이 커지면 커질 수록 다양한 공연들이 많아지게 되고, 그에 따라 Ticket App은 더 복잡한 일을 하게 될 수도 있기 때문이다.



What to name Your Django Apps

App 이름은 되도록 분명하게 짓는 것이 좋다. 예를들어 blog, polls, estimates 같은 것들이다.

PEP 8-compliant에 따르면.

“Python package name: short, all-lowercase names without numbers, dashes, periods, spaces, or special characters"

서로의 편의를 위한 약속같은 것이다. 왠만하면 지키자.


What modules Belong in an App?

Django를 사용하다보면 여러 module을 사용하게 되는데 일반적으로 쓰이는 것과 아닌 것을 모두 살펴보도록 하자.
  1. Common App Modules
# Common modules

apps/
__init__.py
admin.py
forms.py
management/
migrations/
models.py
templatetags/
tests/
urls.py
views.py

이 Module들은 Django App이 만들어질 때 자동으로 만들어지는 모듈들이다. 이렇게 만들어진 Module을 잘 이용하는 것은 다른 사람들이 당신의 코드를 이해하기 쉽게한다.
2. Uncommon App Modules

# Uncommon modules

apps/
behaviors.py
constants.py
context_processors.py
decorators.py
db/
exceptions
fields.py
factories.py
helpers.py
managers.py
middleware.py
signals.py
utils.py
viewmixins.py

이것들은 보통 쓰지 않는 모듈들이다. 하나하나 알아보자

behaviours.py : locating model을 위한 option을 모아논 모듈
constants.py : App안에 주로 쓰는 상수들을 모아논 모듈
decorators.py : App안에서 쓸 decorator들을 모아논 모듈
db/ : custom model fields 나 components가 필요할때 사용
fields.py : form fields를 위해 사용하는 파일. 때로는 db 패키지를 만드는 것을 정의하기 어려울때 model field를 기술하기도 함.
factories.py : test data를 모아놓는 모듈
helpers.py, utils.py : 코드를 좀더 가볍게 만들기위한 helper 함수를 만들어 논 파일, helpers와 utils는 같은 역할을 함
managers.py : models.py가 지나치게 커지면 보편적인 해결책은 해당 모듈에 대한 custom model manager를 만드는 데 이 것을 위한 모듈
signals.py : custom signal을 위한 모듈
viewmixins.py : view module rho packages를 가볍게 만들기 위한 모듈


Summary

Django app의 기술 중 가장 중요한 것은 하나의 App이 하나의 일만을 하게 만드는 것이다. 만약 하나의 앱이 지나치게 복잡한 일을 하고 있다면 여러개의 app으로 쪼개주는 것이 좋다.