인프런 커뮤니티 질문&답변

안녕하세요 이경용님 이렇게 질문 남겨주셔서 감사합니다.

우선 먼저 말씀드리고 싶은 부분은 정답은 없습니다. 어떻게 구현하냐의 차이일 뿐이에요.

저라면 기본 구조는 따라갈꺼 같습니다. API라는 항목은 기존 API 부분에 모두 몰아두고 라우터 path를 통해서 어떤 API인지 명확하게 구분짓게 된다면 우선적으로 기본 틀은 유지가 될 꺼 같습니다.

또한 이 API를 통해 들어오는 요청에 대해서 처리하는 비지니스 로직이 필요할텐데, 해당 부분도 기본에 service 클래스를 작성했던 모듈에서 관리하면 좋을꺼같습니다.

여기서 이제 고려해야 하는 부분은 추가적인 기능들에 대해서 입니다. AI관련 기능이나, 데이터 수집 관련 기능은 현재 모듈에서 구현이 안되어 있는 형태이기 떄문에, 상황에 맞춰서 이 두가지 기능에 대해서는 모듈을 새로 파고 관리하는게 좋지 않을까 싶습니다.

보통 모듈을 파는게 한가지 feature를 기준으로 파기보다는 좀 더 범용적인 기준으로 잡아서 파게 되는데, AI나 데이터 수집 관련된 부분은 기존 서비스 모듈구조에서는 제공하기 애매한 부분이 있어서 새롭게 파는게 좋지 않을까 싶습니다.

기타 예매 관련된 API들에 대해서는 어떤 기능들이 들어가 있을지는 모르겠는데, 기존 모듈구조에서 충분히 소화가능한 기능들이지 않을까 싶습니다.

하지만 앞서 말씀드렸던 것처럼 기준은 없습니다. 경용님이 작업하시면서 '아 이부분은 따로 뺴면 책임이 좀더 명확할꺼 같은데??' 라고 느끼시는 부분을 나눠가시면 좋을꺼 같아요.

질문 주셔서 감사합니다!

안녕하세요, 인프런 AI 인턴입니다. 이경용님.

프로덕션 레벨의 예매 시스템을 구성할 때, 모듈 구조 설계는 매우 중요한 부분입니다. 각각의 모듈이 명확한 책임을 갖도록 설계함으로써 유지보수성과 확장성을 높일 수 있습니다. 두 가지 방법에 대해 살펴보겠습니다.

1. 모든 API 기능을 하나의 API 모듈에서 관리하는 방법은 초기 설정과 개발이 간단할 수 있지만, 시간이 지나면서 각 기능들 간의 복잡도가 증가하고 유지보수가 어려워질 수 있습니다. 모든 기능이 하나의 모듈에서 동작하다 보면, 의존성 관리나 코드의 변경으로 인해 다른 기능에 영향을 줄 가능성이 높습니다.

2. 기능별로 모듈을 나누고, 각 모듈 내에서 해당 기능의 API들을 그룹화하는 방법은 초기 설계에 약간 더 많은 고민이 필요하지만, 장기적으로는 서로 다른 기능들이 독립적으로 작동하도록 도와줍니다. 이러한 설계는 특히 변화에 좀 더 유연하게 대응할 수 있으며, 각 모듈이 독립적이기 때문에 특정 기능의 문제가 다른 모듈에 영향을 주지 않습니다.

다중 기능을 가진 시스템에서는 모듈을 기능 기반으로 나누는 것이 바람직합니다. 이렇게 하면:

• 각각의 모듈이 특정 기능만을 집중하여 책임지고, 관련된 모든 로직을 한 곳에서 관리할 수 있습니다.
  
• 각 모듈이 독립적으로 배포될 수 있어서, 기능별로 별개로 개발 및 릴리스를 할 수 있습니다.
  
• 각 기능의 범위를 명확히 함으로써 코드의 가독성과 협업의 효율성을 높일 수 있습니다.
  

관련된 게시물을 통해 유사한 토픽을 참조해 보시면 깊이 있는 로드맵을 얻을 수 있습니다:

• 모듈 별 API 관리의 이점과 설계 관점
  
• 스프링 프로젝트의 모듈화 전략
  

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.