비즈니스 성장에 맞춰 Django 앱을 발전시키세요

장고앱2
Django로 첫 번째 웹 애플리케이션 프로토타입을 시작할 때 우리는 항상 하나의 Django 앱을 만들고 모든 모델을 해당 앱에 넣는 경향이 있습니다. 이유는 간단합니다. 모델이 많지 않고 비즈니스 로직도 단순하기 때문입니다. 그러나 비즈니스가 성장함에 따라 더 많은 모델과 비즈니스 로직이 추가됩니다. 어느 날 애플리케이션이 어색한 위치에 놓이게 될 수도 있습니다. 버그를 찾는 것이 점점 더 어렵고, 새로운 기능을 추가하는 데 시간이 점점 더 오래 걸립니다. 단순한. 이 블로그에서는 비즈니스 성장에 따라 확장할 수 있도록 다양한 Django 앱을 사용하여 모델과 비즈니스 로직을 재구성하는 방법에 대해 설명하겠습니다. 또한 간단한 사례 연구를 통해 변화의 흐름을 설명하겠습니다.

프로토타이핑 단계 - 간단한 사례 연구

우리는 사용자가 블로그를 만들고 게시할 수 있는 "Weblog"라는 간단한 애플리케이션부터 시작합니다. 우리는 weblog라는 앱을 만듭니다. 그리고 모델은 다음과 같습니다.
In 웹로그/models.py:

클래스 작성자(모델.모델): 사용자 = 모델.OneToOneField('authentication.User') ... 클래스 블로그(모델.모델): 작성자 = 모델.ForeignKey(작성자) 카테고리 = 모델.CharField( 선택=((TECH , 'Tech'), (SPORT, 'Sport'), (FASHION, 'Fashion')), max_length=10 ) content = models.TextField( max_length=10240, 공백=True ) is_published = models.BooleanField(기본값=False ) ...

이제 위의 모델을 기반으로 나머지 애플리케이션이 완료되었다고 가정합니다. 이제 사용자는 우리 애플리케이션을 사용하여 로그인하고 블로그를 만들고 게시할 수 있습니다.
진화하는 접근 방식 I – 동일한 앱에 새로운 비즈니스 로직을 계속 추가합니다.
새로운 요구사항이 있다고 가정해 보겠습니다. 우리 애플리케이션을 사용하여 콘텐츠를 만들도록 더 많은 작성자를 유치하기 위해 조회수에 따라 작성자에게 비용을 지불합니다. 가격은 조회수 10회당 1000달러입니다. 그리고 지급금은 한 달에 한 번 전송됩니다.
새로운 요구 사항은 꽤 간단해 보이기 때문에 기존 앱에 새로운 모델과 로직을 추가하는 일반적인 접근 방식이면 충분합니다. 먼저, 아래와 같이 “weblog” 앱에 새 모델을 추가합니다.
In 웹로그/models.py:

... 클래스 MonthlyViewCount(models.Model): blog = models.ForeignKey(Blog) 월 = models.DateField() count = models.PositiveIntegerField(default=1) ...

블로그의 새로운 보기마다 월을 기준으로 개수를 늘리거나 새 블로그 보기를 만듭니다. 월별 조회수 이번 달 첫 조회수인지 기록해 보세요. 코드는 다음과 같습니다:

class Blog(models.Model): ... def 증가_view_count(self): 지금 = timezone.now() 월 = 날짜시간(년=now.year, 월=now.month, day=1) view_count, 생성됨 = \ MonthlyViewCount .objects.get_or_create( blog=self, Month=month ) 생성되지 않은 경우: view_count.count += 1 view_count.save()

매달 말에 우리는 각 저자의 모든 조회수를 집계하고 이에 따라 지불금을 보내는 cron 작업을 실행합니다. 의사 코드는 다음과 같습니다.
In 웹로그/tasks.py:

@ periodic_task(run_every=crontab(day_of_month=1, hour=0, Minute=1)) def send_viewcount_pay_to_authors(): Authors.objects.authors_with_viewscounts(month=previous_month)의 저자에 대해: total_view_count =author.get_total_view_count_for_month(month=previous_month) Payment_amount = (total_view_count / 1000) * 10.00 작성자.send_결제(결제_금액)

위의 접근 방식은 이와 같은 간단한 변경 요청을 처리하는 데 적합해 보입니다. 하지만 항상 새로운 요구 사항이 들어오게 됩니다.
진화하는 접근 방식 II – 비즈니스 로직을 다양한 Django 앱으로 구성
이제 새로운 요구사항이 생겼습니다. 작성자가 특정 카테고리의 콘텐츠를 만들도록 장려하기 위해 비즈니스 팀은 수상 전략을 카테고리 기반으로 조정하려고 합니다. 각 카테고리마다 보너스 가격이 다릅니다. 보너스 가격표가 다음과 같다고 가정해 보겠습니다.

 가격(조회수 1000회당)
기술$15
스포츠$10
패션$5

또한 이 새로운 요구 사항은 기존 앱에서 새 모델을 생성하여 카테고리 기본 가격을 저장하고 cron 작업을 업데이트하여 총계를 집계할 때 카테고리 기반 가격을 찾을 수 있을 정도로 간단해 보입니다. 전체 변경에는 30분도 채 걸리지 않으며 모든 것이 잘 진행됩니다.
그러나 점점 더 많은 새로운 모델과 비즈니스 로직을 기본 '웹로그' 앱에 적용하는 데에는 두 가지 주요 문제가 있습니다.

  1. 메인 앱은 다양한 도메인 지식의 비즈니스 로직을 담당하게 됩니다. 클래스 파일이 커지고 유지 관리가 불가능해집니다.
  2. 문제를 디버깅하기가 더 어렵고 새로운 기능을 추가하는 속도가 느리기 때문에 민첩성이 저하됩니다.

Django에서는 다양한 앱을 사용하여 다양한 도메인의 비즈니스 로직을 구성하고 앱 간의 통신을 처리하는 신호를 사용할 수 있습니다. 이 예에서는 모든 청구 관련 모델과 방법을 'billing'이라는 새 앱으로 이동하려고 합니다.
먼저, 모든 청구 관련 모델을 새로운 청구 앱으로 옮깁니다.
In billing/models.py:

... 클래스 MonthlyViewCount(models.Model): blog = models.ForeignKey('weblog.Blog', 관련_name='+') 월 = models.DateField() count = models.PositiveIntegerField(기본값=1) ... 클래스 CategoryBasedPrice(models.Model): 카테고리 = models.CharField(Choices=((TECH, 'Tech'), (SPORT, 'Sport'), (FASHION, 'Fashion')), 가격 = models.MoneyField(... ) ...

이제 블로그 기사를 새로 볼 때마다 그에 따라 기록할 수 있도록 청구 앱에 정보가 전달되어야 합니다. 이를 위해 “weblog” 앱에서 신호를 정의하고 “billing” 앱에서 단일 핸들러를 생성하여 수신된 신호를 처리할 수 있습니다.
우리는 Blog.increase_view_count()으로 billing/receivers.py 신호 처리기로서:

def 증가_view_count(발신자, 블로그, **kwargs): 지금 = timezone.now() 월 = 날짜시간(년=now.year, 월=now.month, 일=1) view_count, 생성됨 = \ MonthlyViewCount.objects.get_or_create( blog=blog, Month=month ) 생성되지 않은 경우: view_count.count += 1 view_count.save()

그러면 새로운 신호가 생성됩니다. 웹로그/signals.py:

django.dispatch import에서 청구서 가져오기 수신자의 신호 ... blog_viewed = Signal(providing_args=['blog']) blog_viewed.connect(receivers.increase_view_count)

또한 뷰 메소드 중 하나에 신호 전송 스니펫을 삽입해야 합니다. 웹로그/views.py:

weblog.signals import blog_viewed ... def view_blog(request, blog_id): 시도: blog = Blog.objects.get(blog_id) 제외 ValueError: raise Http404() blog_viewed.send(Blog, blog=blog) response.write( blog.render_content()) 응답 반환

마지막으로 결제 관련 cron 작업을 이동할 수 있습니다. send_viewcount_pay_to_authors웹로그/tasks.py billing/tasks.py 새로운 카테고리 기반 가격 책정을 처리하는 새로운 논리를 추가합니다.
단순히 새로운 모든 것을 기본 앱에 넣는 일반 접근 방식과 비교할 때 위의 접근 방식에는 더 많은 코드 변경과 리팩토링이 필요하지만 가치 있는 몇 가지 장점이 있습니다.

  1. 특정 도메인의 비즈니스 로직은 다른 도메인과 분리되어 코드 베이스를 더 쉽게 유지 관리할 수 있습니다.
  2. 런타임 중에 문제가 발생하면 증상을 기반으로 앱 범위에서 원인을 신속하게 찾을 수 있습니다. 이렇게 하면 디버깅 시간이 단축됩니다.
  3. 새로운 개발자가 온보딩하면 먼저 단일 앱 작업을 시작할 수 있으며 이를 통해 학습 곡선이 조정됩니다.
  4. 특정 도메인에서 전체 비즈니스 로직 세트를 더 이상 사용하지 않기로 결정한 경우(예: 모든 청구 기능이 더 이상 필요하지 않음) 간단히 해당 앱을 제거하면 다른 모든 항목은 계속해서 정상적으로 실행됩니다.

결론
많은 스타트업이 Django를 사용하여 제품이나 서비스의 프로토타입을 만들고 있습니다. 게다가 Django는 비즈니스 성장을 꽤 잘 처리할 수 있습니다. 중요한 측면은 비즈니스 로직을 수시로 다른 앱으로 다시 생각하고 재구성하고 각 앱의 책임을 최대한 단순하게 유지하는 것입니다.

비슷한 게시물