모놀리스 vs 마이크로서비스

도메인 경계 (Bounded Context):
- 이커머스 → 사용자·상품·주문·결제·배송·알림

분해 방법:
1. 데이터 응집도 — 같은 데이터 사용 = 같은 서비스
2. 변경 빈도 — 자주 바뀌는 것 분리
3. 팀 경계 — 팀별 독립 운영
4. 비기능 요구사항 — 결제는 보안 강화, 추천은 ML 인프라

모놀리스 OrderApplication (단일 DB)
    ↓ 분해
- UserService (PostgreSQL)
- ProductService (PostgreSQL + Elasticsearch)
- OrderService (PostgreSQL)
- PaymentService (PostgreSQL + 보안 강화)
- ShippingService (PostgreSQL + Redis)
- NotificationService (PostgreSQL + Kafka)

@FeignClient(name = "product-service", url = "${product.service.url}")
public interface ProductClient {
    @GetMapping("/products/{id}")
    ProductDto getProduct(@PathVariable Long id);
}


@Service
@RequiredArgsConstructor
public class OrderService {
    private final ProductClient productClient;

    public Order placeOrder(OrderRequest req) {
        ProductDto product = productClient.getProduct(req.productId());
        if (product.stock() < req.quantity()) {
            throw new InsufficientStockException();
        }
        // ... 주문 생성
    }
}

1. 네트워크는 신뢰할 수 있다  ❌
2. 지연은 0이다              ❌
3. 대역폭은 무한하다          ❌
4. 네트워크는 안전하다        ❌
5. 토폴로지는 변하지 않는다    ❌
6. 관리자가 한 명이다         ❌
7. 전송 비용은 0이다          ❌
8. 네트워크는 동질적이다      ❌

→ 모든 가정이 깨지는 환경 — 회복 탄력성·관측 필수

✅ 도입 적합:
- 100+ 개발자, 여러 팀
- 서비스별 다른 배포 주기
- 일부 서비스만 고가용성 필요
- 다양한 기술 스택 활용

❌ 도입 부적합:
- 1~10인 팀
- 트래픽 적음 (10만 RPS 이하)
- 도메인 경계 불명확
- 운영 인프라 부재