이 프로젝트는 DDD 철학에 걸맞는 헥사고날 아키텍처 기반으로 멀티 모듈로 구현되었습니다.
*폴더 및 모듈 네이밍과 구조는 수정되고 있습니다.
root
├── common [:common]
├── core
│ ├── exception-handler-webmvc [:exception-handler-webmvc] 🏗
│ └── jpa-core [:jpa-core] 🏗
├── monolith
│ └── main-runner [:main-runner]
└── services
├── user [:user]
├── stream [:stream]
├── chat [:chat]
├── donation [:donation]
├── payment-service [:payment-service]
📂 모듈 구성 자세히 보기
RAIO의 각 도메인은 일반적으로 다음과 같은 구조를 가집니다.
domain ├── api │ ├── domain │ ├── exception │ └── readmodel │ ├── application ├── rdb-adapter ├── webmvc ├── batch └── grpc / redis / socket adapter
각 도메인은 자신의 비즈니스 규칙과 Persistence Adapter를 소유하며, 필요한 Infrastructure Adapter를 선택적으로 구성합니다.
%%{init: {'look': 'handDrawn'}}%%
flowchart TB
monolith/main-runner --> service-module
subgraph service-module
direction LR
board -.->|include| rdb-adapter -.->|include| board-application
board -.->|optional| board-application
board -.->|include| web-adapter -.->|include| board-application
board-application -.->|include| api-module
subgraph api-module
direction LR
board-api -.->|include| domain & readmodel & exception
end
end
service-module -.-> core-modules
core-modules -.-> common
🔎 모듈 의존성 원칙 자세히 보기
- 모든 서브프로젝트에
:common모듈을 의존시킵니다. :board:board-api모듈은 다음 목록을 통합합니다. 그 외 추가 기능을 제공하지 않습니다.:board:board-domain: 도메인 모델을 제공합니다.:board:board-exception: 도메인 관련 예외를 제공합니다.:board:board-readmodel: 도메인 관련 조회 모델을 제공합니다.
:board:board-application모듈은 헥사고날 아키텍처의 각 방향 포트 인터페이스를 제공합니다.:board:board-api모듈을 통합합니다.
:board:board-rdb-adapter및:board:board-webmvc-adapter는 각 포트 인터페이스를 구현하거나 사용하는 어댑터를 제공합니다.:board:board-application모듈을 통합합니다.
- 위 보드 관련 구현 소스 및 리소스를 모두 통합하여
:board모듈을 완성합니다. :board모듈을:main-runner모듈이 통합하고 실행합니다.- 각 코어 모듈은 알맞은 모듈에서 취사선택하여 사용합니다.
*-api 모듈은 다음과 같은 도메인 관련 모듈을 통합합니다.
*-domain: 도메인 모델*-exception: 도메인 관련 예외*-readmodel: 조회 모델*-proto(Optional) : gRPC 통신이 필요한 도메인에서 사용하는 Protocol Buffers 메시지 및 서비스 정의
*-application 모듈은 헥사고날 아키텍처의 UseCase 및 Port 인터페이스를 제공합니다.
Application은 API Module에 의존하지만 외부 Infrastructure 구현에 직접 의존하지 않습니다.
*-rdb-adapter, *-webmvc, *-grpc-*, *-redis-* 등의 Adapter는 Application Port를 구현하거나 사용합니다.
이를 통해 비즈니스 로직과 Infrastructure를 분리합니다.
- JDK 21
You can use OpenJDK e.g. Amazon Corretto 21 - Docker
- 도커 버전이 최신 버전이 아니라면, 도커 컴포즈 또한 필요할 수 있습니다.
- 윈도우 10 사용자 중 일부는 도커가 동작하지 않을 수 있습니다. (세부 버전이 오래된 버전일 때)
1. git clone git@github.com:RAIO-Project/raio-backend.git
2. ./compose-monolith up -d
(권한 필요 시 chmod +x compose-monolith)
3. Please include 'local' profile to your active profiles.
4. Run MainApplication!
RAIO Wiki에서는 프로젝트를 개발하며 축적한 도메인별 비즈니스 프로세스, 아키텍처 설계, 기술 학습 내용과 문제 해결 과정을 기록하고 공유합니다
| Documentation | Description |
|---|---|
| 🏗️ Architecture | DDD · Hexagonal Architecture · Multi-Module 설계 및 발전 과정 |
| 💬 Chat & Moderation | Redis Stream · AI Moderation · Retry · 멱등성 |
| 💳 Payment | Payment · Wallet · Settlement 도메인 설계 |
| ⚙️ Batch Architecture | Spring Batch Core · Batch Server 구조 |
| 🔗 gRPC | 도메인 간 통신 및 서비스 분리 전략 |
| 🚀 Performance & Load Testing | 부하 테스트 · 병목 분석 · 성능 개선 |
| 🔥 Troubleshooting | 장애 분석 및 문제 해결 기록 |
의존성 제공은 compileOnly를 선호합니다. (컨슈머 모듈이 의존성 활성화를 결정)
- 의존 모듈: 다른 모듈에 사용되는 모듈
- 컨슈머 모듈: 의존 모듈을 사용하는 모듈
Compile Only 전략
의존 모듈은 자신의 코드에 필요한 의존성을 compileOnly로 제공하는 것을 선호합니다.
dependencies {
compileOnly("org.example:target-artifcat:version-name")
}- 활성화: 컨슈머 모듈에 별도로
implementation등으로 추가합니다. - 비활성화: 아무것도 추가하지 않고 무시할 수 있습니다.
- 이 방식은 의존성을 기입을 추가로 요구하지만, 컨슈머 모듈이 의존성 선택에 자유도를 갖습니다.
API 전략
의존 모듈은 필수로 함께 사용되는 기능을 api로 제공합니다.
- 모듈 사용을 쉽게 만들지만, 컨슈머 모듈에 기본적으로 의존성이 전이됩니다.
- 다음 방식으로 의존성 선택에 별도로 자유도를 확보할 수 있습니다.
implementation(project("targetModuleName")) { // 단, 이러한 제외가 많아지면 가독성을 해치고 실수가 많아 관리에 까다롭습니다. exclude(group = "org.example", module = "unwanted-artifact") }
협업을 소개하는 별도 문서를 준비하지 않았습니다. 깃허브 협업은 다음을 참고하세요.
개발자들은 다음과 같은 Branch Rule을 꼭 숙지하고 준수해 주시기 바랍니다. (간소화된 브랜치 운영)
-
main 브랜치는 읽기 전용 입니다.
-
feature 브랜치: 모든 변경 사항은 feature 브랜치를 생성 후, main 브랜치로 병합해야 합니다.
-
feature/기능명양식으로 명명하며, 영문 소문자, 숫자 및 하이픈(케밥 케이스)를 사용합니다. (추가적인 슬래시를 사용하지 않습니다.)LoadinggitGraph commit commit branch feature/board-example branch feature/board-something checkout feature/board-example commit checkout feature/board-something commit commit checkout feature/board-example commit checkout main merge feature/board-example checkout main merge feature/board-something commit
-
-
주요 브랜치에 병합 전 Pull Request(PR)는 필수입니다.
커밋 메시지의 제1 규칙은 '알아볼 수 있는 메시지 전달'입니다.
보편적인 앵귤러 커밋 메시지 컨벤션을 따르면서, 각 포맷의 바운더리와 표현 수준은 팀에 맞게 차근차근 조정해 가면 좋겠습니다.
커밋 메시지의 첫 단어는 작업의 목적을 명확히 하기 위해 커밋 타입으로 시작합니다.
type(scope): subject in lowercase
아래의 타입을 실습으로 사용해 보시면 좋습니다.
- feat: 기능 개발
- fix: 버그 수정
- docs: 문서 생성 및 수정 (README.md 등)
- refactor: 코드 리팩토링 (기능 변화 없음: 패키지 이동, 파일·식별자 수정 등)
- test: 테스트 코드 추가 또는 수정
- chore: 코드의 구조나 동작에 영향을 주지 않는 기타 작업
- build: 빌드 관련 작업, 패키지 매니저 설정 등