[SAMBAD-237] 멀티 모듈 기반 프로젝트 구조 마이그레이션

[kkjsw17]

✔️ PR 타입(하나 이상의 PR 타입을 선택해주세요)

• 기능 추가
• 버그 수정
• 의존성, 환경 변수, 빌드 관련 코드 업데이트
• 기타 사소한 수정

📝 개요

• 기존 싱글 모듈 프로젝트 구조를 멀티 모듈로 마이그레이션합니다.
• 각 모듈은 아래와 같이 구성됩니다.
  1. moring-global-utils: 유틸성 모듈로, 모든 모듈에서 범용적으로 사용될 수 있는 클래스가 포함되어야 합니다.
  2. moring-infra: 구현 기술에 관련된 클래스가 포함됩니다. 각종 설정, 또는 설정에 필요한 구현이 포함됩니다.
  3. moring-domain: Moring 서비스의 도메인 관련 클래스가 포함됩니다. DDD의 domain, infrastructure 계층이 포함되며, application 계층의 포함 여부는 논의가 필요합니다.
  4. moring-api: Moring 서비스의 REST API가 구현됩니다. DDD의 presentation 계층에 해당합니다.
• 멀티 모듈 설정을 위해 build.gradle, setting.gradle 및 CI/CD actions 파일을 변경합니다.
• 우선, Controller를 제외한 모든 클래스는 moring-domain 모듈로 이동합니다.
  • 추후 presentation 계층 의존성을 완전히 걷어낼 예정입니다.

🔗 ISSUE 링크

• resolved SAMBAD-237

[LeeHanEum]

마이그레이션 하느라 고생 많으셨습니다 👍
application 계층을 domain 모듈에 위치 시킬지 논의가 필요하다고 하셨는데요,
보통 api 모듈에 application 계층을 위치시키는 것이 일반적이더라구요.

domain : 엔티티와 비즈니스 로직
api : controller service 등 변화가 잦고 다른 모듈과 협력하여 기능을 처리하는 계층

이런식으로 이해하고 있었는데, 저희 프로젝트에서는 domain 모듈에 application 계층을 위치시킨 이유가 있으실까요?

[github-actions]

Unit Test Results

0 tests   0 ✔️  0s ⏱️
0 suites  0 💤
0 files    0 ❌

Results for commit 13c71c9.

[kkjsw17]

마이그레이션 하느라 고생 많으셨습니다 👍 application 계층을 domain 모듈에 위치 시킬지 논의가 필요하다고 하셨는데요, 보통 api 모듈에 application 계층을 위치시키는 것이 일반적이더라구요.

domain : 엔티티와 비즈니스 로직 api : controller service 등 변화가 잦고 다른 모듈과 협력하여 기능을 처리하는 계층

이런식으로 이해하고 있었는데, 저희 프로젝트에서는 domain 모듈에 application 계층을 위치시킨 이유가 있으실까요?

일단 저희 프로젝트가 infrastructure 계층이 application 및 presentation 계층 참조하고 있는 부분이 많아서,
얘네 api 모듈로 보내면 난리가 납니다.

multi module 사례 많이 참고해보면서, 차차 개선해나가면 좋을 것 같아요