4장. 장고 앱 디자인의 기본

장고 앱 디자인 용어

A Django project

• Django web framework를 기반으로 한 web application을 지칭

Django apps

• 프로젝트의 한 기능을 표현하기 위해 디자인된 작은 라이브러리를 지칭
• Django project는 다수의 Django app으로 구성되어 있다.
• app중 일부는 프로젝트 내부적으로 한 번만 이용되고 재사용되지 않기도 한다. 또는 때때로 외부 장고 패키지를 지칭하기도 한다.

Third-party Django packages

• python package 도구들에 의해 패키지화된, 재사용 가능한 플러그인 형태로 이용 가능한 장고 앱을 지칭한다.

4.1. 장고 앱디자인의 황금률

제임스 베넷(James Bennett)는 장고 코어 개발자이자 릴리스 매니저이고, 그의 말을 인용 하자면

"좋은 장고 앱을 정의하고 개발하는 것은 더글라스 맥얼로이(Douglas Mcllroy)의 유닉스 철학을 따르는 것이다. '한 번에 한 가지 일을 하고 그 한가지 일을 매우 충실히 하는 프로그램을 짜는 것이다'"

• 핵심은 각 앱이 그 앱의 주어진 임무에만 집중할 수 있어야 한다는 것이다. 앱이 너무 커질 대로 커진다면 여러 개로 나누어야 한다.

4.2. 장고 앱 이름 정하기

규칙 1

• 가능한 한 flavors, animals, blog, polls, dreams, estimates, finance 같은 한 단어로 된 이름을 이용하자. 앱 이름이 명료하면 프로젝트 관리가 쉬워진다.
• 앱 의 이름은 앱의 중심이 되는 모델 이름의 복수 형태가 되어야 한다.

규칙 2

• 단순히 앱의 메인 모델만을 고려하지 않아야 한다.
• 이름을 정할 때 URL의 주소가 어떻게 되는지도 고려해야 한다.

규칙3

• PEP-8 규약에 맞게 import될 수 있는 이름을 이용하도록 한다.

원서

• Use valid, PEP 8-compliant, importable Python package names:
• short, all-lowercase names
• without 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.

4.3. 확신 없이는 앱을 확장하지 않는다.

앱을 디자인하는 데 너무 완벽해지려고 고민하지 않아도 된다. 앱을 디자인하는 것은 기술적인 문제, 완벽을 요구하는 난해하고 심오한 순수 과학 분야의 연구가 아니다. 때때로 앱을 다시 쓰거나 분리해야 한다.

앱들을 될 수 있으면 작게 유지하려고 하자, 거대한 크기의 앱 두세 개를 구성하는 것보다는 작은 앱 여러 개를 구성하는 것이 훨씬 나은 구성이라는 사실을 명심하기 바란다.

Try and keep your apps small. Remember, it’s better to have many small apps than to have a few giant apps.

4.4. 앱 안에는 어떤 모듈이 위치하는가?

4.5.2 The Large Single App Project

4.5 Ruby on Rails 스타일 접근 방식

일부 사람들은 Ruby on Rails 스타일의 접근 방식을 이용하여 성공을 거두었고, Rails와 Django는 거의 같은 시대에 성공적인 애플리케이션 프레임워크 이다.

Django와 Rails, Python과 Ruby 사이에는 접근 방식을 검토할 가치가 있을 만큼 유사 하다.

4.5.1 서비스 레이어 (Service Layers)

Django로 코딩할 때 초보자가 비즈니스 로직을 어디에 둬야 하는 결정에 대한 어려움을 겪는 것은 흔한 일이다.

Django로 코딩할 때 초보자가 비즈니스 로직을 어디에 두는 결정에 어려움을 겪는것은 흔한 일이다. 고전적인 예로는

일반적인 Django 비즈니스 로직 배치

class UserManager(BaseUserManager):
"""In users/managers.py"""
def create_user(self, email=None, password=None, avatar_url=None): 
        user = self.model(
                email=email,
                is_active=True, 
                last_login=timezone.now(), 
                registered_at=timezone.now(), 
                avatar_url=avatar_url
        )
        resize_avatar(avatar_url) 
        Ticket.objects.create_ticket(user) 
        return user

class TicketManager(models.manager): 
        """In tasks/managers.py"""
        def create_ticket(self, user: User):
                ticket = self.model(user=user) 
                send_ticket_to_guest_checkin(ticket) 
                return ticket

Service Layers

# Service layer 예제
scoops/
├── api/
├── models.py
├── services.py  # Service layer location for business logic
├── selectors.py  # Service layer location for queries
├── tests/

Service Layer Business Logic Placement

# In users/services.py
from .models import User
from tickets.models import Ticket, send_ticket_to_guest_checkin
def create_user(email: str, password: str, avatar_url: str) -> User:
    user = User(
        email=email,
        password=password,
        avatar_url=avatar_url
    )
    user.full_clean()
        user.resize_avatar()
        user.save()

        ticket = Ticket(user=user)
        send_ticket_to_guest_checkin(ticket) 
        return user

• Django Styleguide ( 링크 )
  • 잠깐 살펴봤는데 개발할때 보면 좋을 것 같습니다.

위의 접근 방식의 장점

1. 17줄에서 12줄로 심플 해진다 ?
2. 느슨한 결합은 사용자 또는 티켓팅 코드를 쉽게 교체 할 수 있다.
3. 관심사를 분리하면 개별 구성 요소의 기능 테스트를 더 쉽게 수행할 수 있다.

위 접근 방식의 단점

1. 소규모 프로젝트의 경우 불필요한 복잡성이 추가되는 경우가 많다
2. 복잡한 프로젝트의 경우 서비스 계층은 일반적으로 수천 줄의 코드로 확장 되는데 그것을 지원하기 위해 새로운 아키텍처의 개발이 강요 된다.

요약

• 각각의 장고 앱은 그 앱 자체가 지닌 한 가지 역활에 초점이 맞추어져야 하며 단순하고 쉽게 기억되는 이름을 가져야 한다.
• 앱의 기능이 너무 복잡하다면 여러 개의 작은 앱으로 나누어야 한다.
• 올바른 앱을 디자인하는 것은 많은 노력과 연습을 필요로 하지만 충분히 가치 있는 일이다.