도메인 관련 로직들은 어디에 작성되는 것이 좋을까요?

[donghyun0218]

도메인 관련 로직을 작성하는 위치에 대한 논의를 해보고자 첫 Discussion 을 열었습니다.

Django 어드민에서 선택한 상품들을 일괄적으로 품절 상태로 업데이트 할 수 있는 액션을 만들어주세요.

온라인 쇼핑몰 서비스에서 관리자로부터 위와 같은 요구사항에 생겼을 때, 처리할 수 있는 방법은 아래와 같이 크게 두 가지가 있을 것 같습니다.

# admin.py

class ProductAdmin(admin.ModelAdmin):
    # ...some code...
    def set_sold_out(self, request, queryset):
        for product in queryset:
            product.is_sold_out = True
            product.save()

# admin.py

class ProductAdmin(admin.ModelAdmin):
    # ...some code...
    def set_sold_out(self, request, queryset):
        for product in queryset:
            product.set_sold_out()

저 같은 경우는 아래와 같이 도메인 관련 로직들은 모두 해당 도메인에 가까운 모델에 작성합니다.

아래의 방법으로 코드를 짤 때의 장단점은 다음과 같은 것들이 있을 것 같습니다.

장점

• 도메인 관련 로직이 한 곳에 모두 모여있어서 모델이 하는 동작을 명확히 알 수 있습니다.
• 모델이 변경되는 시점을 쉽게 추적할 수 있습니다.
• 도메인 로직을 호출하는 부분의 코드가 간단해집니다. 예를 들어 어드민 또는 뷰에서는 도메인 관련 모델의 메서드만 호출하게 됩니다.

단점

• 한 번만 사용되는 로직이더라도 모델에 작성되게 되어서, 모델이 뚱뚱해질 수 있습니다.

제 생각에는 도메인 로직들을 모델 또는 서비스 클래스에 담는 것이 프로젝트 관리에 있어서 긍정적인 효과를 불러올 수 있다고 생각합니다.
여러분들 생각은 어떠신가요?

[Kirade]

동현님께서 말씀하시는 도메인 관련 로직의 의미와 조금 차이가 있을 수는 있는데요.

저는 모델 인스턴스의 정보를 변경하는 로직들이 (보통은 비즈니스 로직) 모델 인스턴스 메서드로 구현되면 좋다고 생각합니다.

위에서 말씀해주신 것 이외에도 다음과 같은 장점이 있는것 같아요.

• 동일한 기능을 하는 코드가 여러 뷰에 흩어져 있는 경우에는 기능의 변경이 생겼을 때, 동일한 기능을 구현한 코드를 모두 찾아서 일일이 고쳐야하는 불편함이 존재하는데요. 이 경우 모델 인스턴스 메서드에 다른 코드들이 의존하고 있으면 신경써서 고쳐야 할 코드의 양이 적어지기 때문에 기능의 변경이 수월해 집니다.
• 그리고 위와같이 룰을 정하게 된다면 기능을 보면서 구현을 찾거나, 구현을 보면서 사용처를 찾으려 할 때 빠르게 검색이 가능하다는 점도 있습니다.

[donghyun0218]

넵 의견 감사합니다. 재영님 생각에 동의합니다.

그렇다면 모델 매니저에 작성해야 하는 로직들은 어떤 것들이 되어야 한다고 생각하시나요?

저는 모델 데이터 생성 계산과 같은 로직들이 모델 매니저에 들어가야 한다고 생각합니다.
본문 예시에서 언급한 도메인(온라인 쇼핑몰)을 사용해서 이야기 하자면, 상품의 생성 로직 또는 특정 기간동안의 상품 판매액 계산 로직들이 모델 매니저에 정의되는 것이 좋다고 생각합니다.

[Kirade]

A Manager is the interface through which database query operations are provided to Django models. At least one Manager exists for every model in a Django application.

장고의 공식문서에서 말하는 매니저는 모델의 데이터베이스 쿼리를 위한 인터페이스라고 소개를 해주고 있습니다.
저는 최대한 장고가 의도한 바에 맞추어 사용하려고 노력하는 편인데요.

말씀하신 기능들 ( 상품의 생성, 상품 판매액의 계산 ) 은 모두 데이터베이스 쿼리를 통해 이뤄지기 때문에 매니저에서 정의되기 적절하다고 생각합니다.
가령 상품의 삭제와 같은 기능이 필요하면 이것 또한 매니저에 정의하는것을 고려해볼 것 같아요.

[twins1040]

두분 의견에 동의합니다.

구체적 사례를 통해 확인하고 싶은게 있는데요,
관계된 모델을 aggregation 하고 싶은 경우 아래와 같이 하면 된다는 것이죠?

class Product(models.Model):
    ...
    @property
    def net_income(self):
        return self.payments.net_income()  # Payment 에 정의된 순이익 queryset net_income 사용

아래와 같이 작성하는분이 있을 수도 있을 것 같아서요

Product.objects.get_net_income(product=product)

[anohk]

명욱님이 말씀하신 것 처럼 첫 번째 방식으로 사용하는 것이 적절해보여요.
사례는 Payment 쿼리셋의 aggregation 결과를 얻는 것이 목적이고, Payment 쿼리셋 매니저 인터페이스를 바로 사용할 수 있는데
두번째와 같이 작성하는 경우 Product 모델 매니저 인터페이스를 한번 더 거쳐가는 상황이 만들어지네요.

[donghyun0218]

넵 저도 명욱님의 첫 번째 예시가 더욱 적절하다고 생각합니다.
Product 인스턴스에 대한 net_income 을 얻고 싶다면 모델 메서드로 정의가 되는 것이 적절한 것 같습니다.

[donghyun0218]

논의 내용을 바탕으로 PR 을 만들도록 하겠습니다.