[🔥TroubleShooting - TicToc🔥] 장기 프로젝트 이대로.. 괜찮을까..❓💦💦

📌 프로젝트 소개

팀원 : 개인 프로젝트
기간 : 2025.01 ~ 진행 중
링크 : https://github.com/M-ung/TicToc_Server
서비스 내용 : 당신의 시간에 가치를 매기다, 시간 거래 경매 플랫폼

---

🔥TroubleShooting🔥

Problems

초기 개발 단계에서 레이어드 아키텍처 기반 단일모듈로 프로젝트를 구성했다. 하지만 개인 프로젝트로서 장기적으로 지속적인 개발이 필요했기 때문에 확장성을 고려한 설계가 필요했다.

---

How

헥사고날 아키텍처를 적용하여 비즈니스 로직과 데이터 접근 로직을 분리하고, 멀티모듈로 변경하여 하나의 모듈에 코드가 쌓이는 것을 방지하고자 했습니다.

---

Process

클라이언트가 요청을 보내면, 먼저 tictoc-api 모듈의 Controller 계층에서 이를 수신한다. 그 다음, 비즈니스 로직의 인터페이스 계층인 UseCase를 통해 요청이 전달되며, 해당 요청은 구현체인 Service 계층에서 처리된다.
비즈니스 로직 과정에서 도메인 객체 및 DB 접근이 필요할 경우, tictoc-domain 모듈의 Port 인터페이스를 통해 데이터를 요청한다. 그 다음, Port 인터페이스의 구현체인 Adaptor는 Repository를 활용하여 DB에 접근하여 수행하는 흐름이다.

위 사진을 보면 DB가 Master와 Slave로 나눠져 있고, Query와 Command라는 단어가 보인다. 이는 다음 글에서 자세히 다루겠지만, 이해를 돕기 위해 간단히 설명하겠다.

Query와 Command를 나누는 기준은 크게 역할이 "쓰기"냐 "읽기"냐에 따라 결정한다. 이렇게 하는 이유는 CQRS패턴, DB분리, 속도 개선, 등 여러 이유가 있겠지만, 저는 프로젝트를 최대한 모듈화하고 싶고 객체를 역할 별로 깔끔하게 관리하고 싶어서 위 네이밍 법칙을 가져오고 있다.
그리고 이번 프로젝트에서는 DB를 Mysql을 사용하고 있는데, 이를 Master와 Slave로 나눠서 위 위 사진대로 관리할 예정이다.

---

Result

문제 해결로 아래와 같은 결과를 얻었다.
1. 유지보수성 및 확장성 향상.
2. 비즈니스 로직과 데이터 접근 로직 분리.

최종 프로젝트 모듈 형태는 아래와 같다.

또 "경매 등록" 기능을 아래와 같이 헥사고날 아키텍처로 구현했다.

📍 AuctionCommandController.java

📍 AuctionCommandUseCase.java

📍 AuctionCommandService.java

📍 AuctionRepositoryPort.java

📍 AuctionRepositoryAdapter.java

📍 AuctionRepository.java

---

Thoughts

이전까지 단일모듈로 개발을 해왔었고 멀티모듈이 있다는 사실을 이번에 처음 알았다. 이전까지 단일모듈로 개발을 하면서 디렉토리와 클래스의 개수가 늘어날 때마다 관리하고 원하는 파일 찾기가 어려웠었다.
이번 멀티모듈로 변경한 후 개발을 쭉 대략 2개월 가까이 진행해 보았는데, 확실히 원하는 파일 찾기가 단일모듈일 때보다 훨씬 수월해졌다.

헥사고날 아키텍처라는 단어 또한 이번에 처음 들어봤다. 처음에는 클린 아키텍처를 먼저 알게 되었어서 이를 적용해 보려고 했는데, 구글에서 래퍼런스를 찾기가 쉽지 않았다. 그래서 클린 아키텍처에서 파생된 헥사고날 아키텍처가 있다는 사실을 알고 알아보게 되었고, 클린 아키텍처보다 래퍼런스도 많이 있기에 이를 택했다.
적용한 결과, 비즈니스 로직에서 데이터베이스나 외부 API에 직접 의존하는 것이 아니라,
UseCase, Port와 같은 인터페이스를 통해서만 접근할 수 있도록 제한할 수 있었다. 이 덕분에 DB 내용을 변경할 때, 비즈니스 로직을 변경할 필요가 없어지는 장점과 코드가 훨씬 깔끔해지는 효과를 얻을 수 있었다.

마지막으로 헥사고날 아키텍처 중 "도메인과 엔티티"를 분리하는 내용이 있었다. 도메인과 엔티티를 분리하면 비즈니스 로직과 데이터 저장 로직을 명확하게 구분할 수 있어서 유지보수성과 확장성이 향상한다는 장점이 있다.
이를 처음에 적용해 보았지만, 사실 이를 분리해서 얻는 이점보다 코드의 복잡성만 늘어나서 얻는 단점이 크다고 생각했다.
예를 들어 Update 관련 기능을 구현할 때, 도메인과 엔티티를 분리하지 않는다면 "더티 체킹"을 통해 굳이 Save를 다시 할 필요가 없었다. 하지만 도메인과 엔티티를 분리한다면, 해당 엔티티를 JPA를 통해 찾고, 찾은 엔티티를 도메인으로 변경, 도메인을 수정, 도메인을 엔티티로 변경, 엔티티를 JPA를 통해 다시 저장하는 과정을 거쳐야 했다.
그래서 "도메인과 엔티티" 분리는 적용하지 않고 이 글을 마치겠다.

---