[Spring] 패키징 작업 - SJ Coding Helper 프로젝트 리펙토링 (1)

2021년 9월 - 12월까지 시작한 세종 코딩 헬퍼 프로젝트를 리펙토링 하려고 한다.

그때 당시에 Infra 및 백엔드 파트를 담당했는데 기술을 적용할 때 성능은 생각하지 않고 했기에,,

아쉬움이 많은 프로젝트다. 견문을 쌓고 돌아온 지금, 해당 프로젝트를 보고 리펙토링을 할 예정이다.

그 당시에 배운 점 :

1. Docker, Nginx, Spring boot, JPA 등 사용해봤다.

   → 얕게 공부해서 바로 적용한 수준이다.

2. 테이블 무결성을 유지하기 위해 스키마에 신경을 썼다.

   → 얕은 지식이기에 채팅할 때 1:1 구조로만 제약을 걸었다.

   → 다대다 구조로 변경하려면 공사가 필요하다.

3. 웹에서 컴파일러를 실행할 수 있게 기능을 만들었다.

   → 보안에 신경쓰고, 스프링에서 zt-exec 라이브러리로 프로세스를 다뤄봤기에 의미 있었다. 하지만 해당 라이브러리를 사용할 때 깊은 이해를 가지고 적용한 것이 아니기에 깊은 공부가 필요하다.

물론 얕고 넓게 적용하고, 팀원들과 하고 싶은 프로젝트를 한 것이기에 의미있는 프로젝트다.

이 프로젝트를 더 확고히 가져가고 개인의 성장을 위해서 해당 프로젝트를 깊게 파볼 생각이다.

아쉬운 점 :

1. 패키지 구조, 네이밍, 클래스가 하는 역할이 분명하지 않아 스파게티 형태다.
2. 테스트 코드가 없어서 제대로 동작하는 지 확인할 수 없다.
3. 성능을 생각하지 않았다.
4. 기능 추가

먼저 리펙토링 전, 현재 패키지 구조를 보겠다.

현재 패키지 구조의 문제 점 :

config, controller, domain, exception, repository, security, service 구조로 되어있다.

하지만 해당 프로젝트에서는 챗봇 기능, TA조교와 채팅 기능, 코드 컴파일러 기능이 있는데 도메인이 분리되어 있지 않아 관리하기 힘들다.

변경할 패키지 구조:

1. config, core, module, util로 패키지를 나눈다.
2. core에는 전역으로 사용하는 exception, jwt 등을 담는다.
3. config는 외부에서, 내부에서 사용되는 설정 정보를 담는다.
4. module에는 각 도메인으로 나눠서 내부적으로 application, domain, infra, presentation으로 나눈다.
   1. module/user/application 패키지에는 네이밍에 맞게 해당 어플리케이션의 각 레이어에서 사용되는 dto 객체, 어플리케이션의 비즈니스 코드를 담당하는 service 객체를 둔다.
   2. module/user/domain 패키지에는 해당 도메인의 실체와 가까운 객체들을 놓는다. User, Entity, Repo까지 담겠다.
   3. module/user/infrastructure 패키지에는 해당 도메인에서 사용하는 ORM 이나 데이터베이스 연결 방식이 변경될 점을 생각해서 따로 빼준다. (확장을 생각한 패키징)
   4. presentation 패키지는 Controller를 담아준다.
   

위 사진은 변경한 패키지 구조이다. 클래스 네이밍은 손을 봐야겠지만 확실히 구조가 깔끔해졌다.

다음 포스팅은 User Entity 책임 분리로 포스팅을 작성하겠다.