우리는 새로운 기술을 단순히 적용하는 것보다
왜 필요한지 이해하고, 현재 문제에 적합한 기술을 선택하는 과정을 중요하게 생각합니다.

• Backend Engineering을 중심으로 탄탄한 기반을 만듭니다.
• AI를 개발 생산성과 실제 서비스에 적극적으로 활용합니다.
• 기술 선택의 이유를 설명할 수 있는 엔지니어링을 지향합니다.
• 개인의 경험을 팀의 기술 자산으로 축적합니다.
• 서비스의 성장과 함께 개발자의 성장도 중요하게 생각합니다.

RAIO는 Layer보다 Domain을 중심으로 관련 코드를 응집시키고,
각 Domain 내부에서 Hexagonal Architecture를 유지합니다.

payment-service
│
├── payment
│   ├── domain
│   ├── application
│   └── adapter
│
├── wallet
│   ├── domain
│   ├── application
│   └── adapter
│
└── settlement
    ├── domain
    ├── application
    └── adapter

이를 통해 다음을 지향합니다.

High Cohesion · Low Coupling · Clear Boundary · Easy Extraction

비즈니스 기능과 실행 환경(Runtime)을 서로 다른 관심사로 바라봅니다.

        Business Capability

Payment · Wallet · Settlement · Stream
                 │
                 │ UseCase
                 ▼
──────────────────────────────────
                 ▲
                 │
      Online · Batch · Consumer

                Runtime

Domain은 무엇을 수행하는지를 정의하고,
Runtime은 어떻게 실행할지를 결정합니다.

따라서 동일한 Application / Domain을
Online Server, Batch Server, Consumer Server 등 다양한 실행 환경에서 재사용할 수 있습니다.

RAIO는 서비스와 조직의 성장에 따라 경계를 점진적으로 확장합니다.

Monolith / Monorepo
        │
        ▼
  Domain Boundary
        │
        ▼
      Package
        │
        ▼
      Module
        │
        ▼
      Runtime
        │
        ▼
      Service
        │
        ▼
    Repository
        │
        ▼
 Independent Team

처음부터 시스템을 분산시키는 것이 아니라,
필요할 때 분리할 수 있는 구조를 만드는 것을 목표로 합니다.

flowchart LR

    Viewer["👤 Viewer"]
    Stream["📺 Stream"]
    Chat["💬 Chat"]
    Payment["💳 Payment"]
    Wallet["👛 Wallet"]
    Donation["🎁 Donation"]
    Streamer["🎙️ Streamer"]
    Settlement["💰 Settlement"]

    Viewer --> Stream
    Viewer --> Chat

    Viewer --> Payment
    Payment --> Wallet

    Wallet --> Donation
    Donation --> Streamer

    Streamer --> Settlement

RAIO에서 시청자는 방송을 시청하며 실시간 채팅에 참여하고,
포인트를 충전해 스트리머에게 후원할 수 있습니다.

후원으로 발생한 스트리머의 수익은
정산 과정을 통해 집계되고 정산 대상 금액으로 확정됩니다.

각 도메인은 자신의 비즈니스 책임을 가지며
다른 도메인의 내부 구현에 직접 의존하지 않는 것을 지향합니다.

RAIO에서는 Payment와 Settlement를 서로 다른 비즈니스 영역으로 바라봅니다.

Payment ≠ Settlement

사용자가 플랫폼에 돈을 지불하고 포인트를 충전하는 과정입니다.

Viewer
   │
   ▼
Payment
   │
   ▼
Wallet

사용자가 보유한 포인트를 사용하여 스트리머에게 후원합니다.

Viewer Wallet
      │
      ▼
   Donation
      │
      ▼
Streamer Revenue

후원 등을 통해 발생한 스트리머 수익을 집계하고
플랫폼 수수료 정책을 적용하여 최종 정산 대상 금액을 계산합니다.

Streamer Revenue
       │
       ▼
 Gross Amount
       │
       ▼
  Fee Policy
       │
       ▼
 Platform Fee
       │
       ▼
Net Settlement Amount

정산과 실제 지급은 분리합니다.

Donation
    │
    ▼
Settlement
    │
    ▼
Payout / Transfer

현재 RAIO에서는 Settlement까지를 정산 도메인의 책임으로 정의하고,
실제 송금이 필요한 시점에는 별도의 Payout / Transfer 영역으로 확장할 수 있도록 설계합니다.

RAIO에서는 Batch 자체에 비즈니스 로직을 넣지 않습니다.

Batch Server
     │
     ▼
Batch Adapter
     │
     ▼
UseCase
     │
     ▼
Application
     │
     ▼
Domain

예를 들어 정산 Batch는 정산 로직을 직접 구현하지 않고
Settlement Application의 UseCase를 호출합니다.

Settlement Job
      │
      ▼
SettlementCalculateUseCase
      │
      ▼
Settlement Application
      │
      ▼
Settlement Domain

Spring Batch를 사용하는 것이 목적이 아니라,
도메인 개발자가 비즈니스에 집중할 수 있도록 Batch 실행 환경을 추상화하는 것을 목표로 합니다.

서비스 간 통신에서도 Domain과 Application이
특정 통신 기술에 직접 의존하지 않도록 설계합니다.

Application
     │
     ▼
    Port
     │
     ▼
gRPC Adapter
     │
     ▼
   gRPC
     │
     ▼
Server Adapter
     │
     ▼
Application

현재 서비스 간 동기 통신에는 gRPC를 활용하며,
향후 비동기 처리가 필요한 영역은 Event 기반 통신으로 확장할 수 있도록 고려합니다.