클린 아키텍처에 대한 고찰

클린 코드를 쓴 저자의 다른 책 중 클린 아키텍처가 있습니다.
말 그대로 클린한 아키텍처죠. 여기서 말하는 아키텍처는 코드의 아키텍처를 말합니다.
이전 포스팅에서 다뤘던 Kubernetes와는 다른 개념이죠.

프로그래밍을 오래 자주 하다 보면 리팩토링을 자주 하게 됩니다.
이 부분은 앞서 많은 포스팅에서도 기술 부채와 연결해서 얘기했었습니다만..
늘 “그때 맞고 지금은 틀리다”가 성립되는 것 같습니다.

그렇게 반복적으로 리팩토링을 하다 보면
코드 재사용성을 좀 더 개선했다든지, 코드 보기가 좋아졌다든지.. 어찌 됐건 개선점이 있습니다.

예를 들어 초창기에 Django를 사용했을 때는 인증이 필요한 모든 API에
조건문을 넣었었죠.

def get_queryset(self):
    if self.request.user and self.request.user.is_authenticated:
        films = self.request.user.film_set.select_related("film").order_by(
            "-id"
        )
        return films

    return Film.objects.none()

이렇게 모든 코드에 들어가면 좋은 점은 API 코드의 가독성이 정말 좋(다고 생각했)습니다.

그러다 Fluent Python 이라는 책으로 스터디를 한적이 있는데,
이 때 데코레이터를 알고 나서는 직접 login_required 라는 데코레이터를 만들어서 사용했습니다.

@login_required
def get(self, request, *args, **kwargs):
    return self.list(request, *args, **kwargs)

이렇게 작성하면 인증이 필요한 API에 데코레이터만 달아주면 되서 개발이 편해지고
가독성도 좋습니다.
(나중에 알았지만 데코레이터 패턴이라고도 부르더라구요.)

이렇게 “운 좋게 얻어걸린” 몇몇 패턴을 쓰고는 있었습니다만, 말 그대로 얻어걸린 거죠.

최근 코드 아키텍쳐에 관심을 갖게 되면서 현시점의 LAH 코드를 돌아보고
어떤 패턴을 잘 쓰고 있고, 잘못 쓰고 있고 점검하는 시간을 가졌습니다.

현재 운영 중인 서비스들이 공통적으로 처한(?) 상황은 이렇습니다.

• Django REST framework (DRF)에서 제공하는 DI를 일부 사용
• Django의 기본 패턴인 MVC는 유지해서 사용
• 데코레이터 패턴 일부 사용
• libs 디렉토리로 공용 라이브러리를 모아서 관리

자세한 상황이나 코드를 기술할 수는 없지만, 개선이 필요한 부분은 2가지로 보여집니다.
DRF가 제공하는 DI와 그 구조를 적극적으로 활용하고 있지 못하는 것과, 공용 라이브러리의 의존성을 관리하지 못한 부분입니다.
창피한 이야기지만 라이브러리로 개발한 부분을 사용/수정하다 circular import 이슈를 만날 때도 있었습니다.

우선 DRF가 제공하는 DI를 최대한 활용해 보려고 합니다.
제대로 사용 못 하고 있는 permission_classes 필드 사용부터 시작이겠네요.
또 Serializer의 경우도 최소한으로 정의하고 재활용했었는데 오히려 잘못된 접근이라는 것을 알았습니다.

이런 부분이 개선되고 나면 조금 더 가독성 좋고, 수정하기 좋은 코드가 될 것 같네요.

class FilmView(mixins.ListModelMixin, generics.GenericAPIView):
    pagination_class = FilmPagination
    serializer_class = FilmSerializer
    permission_classes = ('isAuthenticated',)

    def get_queryset(self):
        return Film.objects.all()

def get(self, request, *args, **kwargs):
    return self.list(request, *args, **kwargs)

이렇게 되길 바라봅니다 🙂

• 

• 

• 

• 

• 

• 

• 

• 

• 

---