새로운 아키텍처 고민

[Dong-Hyeon-Yu]

— 현재 문제점(2021-10-21) —

1. views, DB, 권한간 의존성이 커서 서로 종속적이다. 하나가 수정될 시에 다른 여러곳에 영향을 미칠텐데 그 영향을 최소화할 필요가 있다.

   1. (DB 와 views)
      1. spring의 dao, domain, dto 와 같은 형태 도입이 필요해보임
      2. view 안에서 db 속성값을 기술하니, 가독성이 떨어짐
      3. db 최적화 등의 이유로 추후 db 모델을 변경할 때, 모든 views 에서 일일히 변경해야함. 다 완벽하게 찾을 수 없음.
      4. 장고 ORM 쿼리를 views 에서 직접 날리는 것 안좋은 듯.
   2. (DB 와 forms)
      1. 현재는 클라이언트 사이드를 장고 템플릿 언어로 해결하고 있지만, 향후 vue로 분리될 것을 생각하면, forms 는 vaildation의 역할만 하게 됨.
      2. forms 에서도 ORM 쿼리를 직접 날리는 부분이 꽤 많음. 즉 ORM 객체에 대한 변경 수정이 여기서도 이루어짐
   3. 테스트 코드 작성의 어려움. 최대한 외부 종속성을 줄여서, 순수함수의 형태로 만드는 것이 필요해보임.

2. 따라서 DB 기존의 MVT 모델, hierarchical 하게 의존성을 제거하는 아키텍쳐 고안 필요성 제고.

   1. core를 담당하게 되는 entity.py 정의
   2. ORM객체를 가져와 entity로 변환하는 repository.py (DB 와 server API core 사이의 인터페이스), ORM 상세를 신경쓰지 않도록 한다.
   3. Use Case 에 대한 로직을 담당하는 interactor.py, ORM 객체가 아닌 repository.py 를 통해 변환된 Entity를 다룬다.
   4. views 에서는 interactor.py 에 정의된 클래스 객체를 이용하여 Use Case에 적절히 대처. 또한 'serializer' 등이 여기서 사용될 수 있다. views 는 (response, status) 형태의 리턴값을 갖는다. 주의할 점은, 함수나 클래스 내부에서 종속되게 사용하는 것이 아니라, 외부에서 주입하는 형태로 사용해야함.
   5. views 외부의 의존성 : vaildation / auth check / ... ⇒ views Wrapper 에서 처리. 즉 기존의 web과 통신하는 views 역할을 views Wrapper 가 하고 views 는 response와 status만 리턴해준다.

   ⇒ 기대효과

   1. 테스트에 용이. 현재는 views 함수 내부에서 직접 ORM, 유저 권한 , 세션 등에 직접 관여하고 있어서, 테스트가 거의 불가능하다. 외부에서 주입할 수 있는 형태가 되고, 서로 다 분리가 되기 때문에 독립적으로 테스트가 가능하다.

   2. 비지니스 로직을 작성하는데 있어서, 기존에는 ORM의 상세한 부분까지 알고 있어야 했다. 예를 들어 Board.object.get(board_type_id = 4) 라는 쿼리가 있으면 4에 해당하는 게시판 종류가 뭔지 알고 있어야 했다. 하지만 Entity 에 noticeBoard 클래스로 따로 선언하게 되면, 해당 ORM 상세를 모두 외우고 있지 않아도 개발이 가능하다.

   3. 유지 보수에 더욱 편리해진다. 각각의 레이어에 대해 각자 전담하는 부분이 생긴다. entity.py 는 개발내에 사용할 객체, repository 는 ORM과 entity 사이의 관계 기술, 이런 식으로 각자 맡은 역할이 뚜렷하다. 기존에는 views 에서 이런 것들이 통합적으로 이루어졌는데 해당 부분에 대해서 수정사항이 생길 시에는, 유지보수를 하기 힘들었다. 예를 들어 orm의 상세가 조금 바뀌었다고 해보자. 그러면 views 에서 orm 을 얻어오는 모든 코드들을 점검해야했는데, 위의 아키텍처 적용 시 repository 에서만 변경해주면 된다.

   ⇒ 단점

   1. 계층이 많아지는 만큼, 보일러 플레이트도 증가
   2. 현재 운영 중인 서비스에 영향을 주지 않으면서, 점진적으로 교체해야한다.

[Dong-Hyeon-Yu]

• 아키텍처 참고 링크1
• 아키텍처 참고 링크2
• 클래스 다이어그램 참고 링크

[Dong-Hyeon-Yu]

Django vs Spring

models.py ----- entity.java
entity.py ------- dto.java (beans)
repository.py -- dao.java (repository.java)
interactor.py -- service.java
views.py ------- controller.java

내가 너무 용어를 헷갈리게 적어놔서
spring 기준으로 비교해서 적어봤음!
spring으로 개발을 해본적이 없어서 맞을 지 모르겠네
DDD(Domain Driven Development) 도메인 주도 개발 참고!
@MingyeomKim

[Dong-Hyeon-Yu]

@MingyeomKim 공지사항 게시판 json 응답하는거 구현해봤음! 커밋참고!

[Dong-Hyeon-Yu]

링크: 오늘 @MingyeomKim 이가 얘기했던 부분!
spring 하자는 얘기가 있었는데,,

1. 지금 템플릿 쪽도 장고가 렌더링하고 있는 게 있다.
2. 프론트가 완전하게 분리되는 작업을 진행 중..
3. 완전하게 restful API 서버가 아닌 상황에서 스프링으로 바꾸게 되면, tomcat/nginx/templateEngine 등 영향이 있고, 서비스를 안정적으로 운영하기 힘들다.
4. 하지만 아키텍처에 대한 고민을 할수록 장고의 단점이 보이기는 한다.
5. 추후 프론트와 완전히 분리되어 API 서버의 역할을 수행하게 되면, 조금씩 스프링으로 migration 해보는 것도 괜찮을 거 같다.

일단 우리 상황에 맞는 아키텍쳐에 원리를 고민하고 그걸 파이썬으로 구현해보자! 원리만 잘 파악하면 나중에 스프링할 때도 아키텍처에 대한 고민은 훨씬 수월할 것! 근데 확실히 스프링 기능이 탐나긴 한다. 허허