Architecture

전략적 설계(Strategic Design) 는 큰 그림을 그립니다. 비즈니스를 어떤 하위 도메인으로 나눌 것인가, 각 하위 도메인에 어떤 경계를 그을 것인가(Bounded Context). 전술적 설계(Tactical Design) 는 각 Bounded Context 안을 어떻게 구현할 것인가를 다룹니다.

CQRS가 필요한 시점을 알려주는 신호가 몇 가지 있습니다. 가장 명확한 신호는 읽기와 쓰기의 스케일링 방향이 달라지는 때입니다. 주문 도메인에서는 결제 처리, 상태 전이, 재고 차감이 쓰기 집약적 작업이고, 주문 목록 조회, 매출 집계, 배송 추적 현황은 읽기 집약적 작업입니다.

Feature flag의 가장 큰 가치는 배포(deploy)와 출시(release)를 분리하는 것입니다. 코드는 production에 배포하되, 기능은 특정 사용자에게만 켜거나 아예 꺼둘 수 있습니다. 이 단순한 분리가 배포 리스크를 크게 낮춥니다. 문제가 생기면 rollback 대신 flag를 끄고, 새 기능은 내부 사용자부터 천천히 열 수 있습니다.

분산 시스템에서 가장 불편한 진실은 "데이터베이스 커밋"과 "메시지 발행"을 하나의 원자적 동작으로 묶기 어렵다는 점입니다. 주문 서비스가 결제를 승인하고 orders 테이블에 상태를 저장한 뒤, Kafka나 RabbitMQ로 OrderPaid 이벤트를 발행한다고 가정해봅시다.

웹 애플리케이션의 규모가 확장됨에 따라, 단일한 소스 코드 저장소와 단일한 빌드 파이프라인을 가진 모놀리스 구조는 여러 가지 병목 현상을 야기합니다. 1.1. 기하급수적으로 증가하는 빌드 및 배포 시간 코드베이스가 수십만 줄에 이르고 관리되는 정적 에셋이 늘어날수록 빌드 시간은 선형적이지 않고 기하급수적으로 증가하는 경향이 있습니다.

기업이 성장하면 제품의 수도 늘어납니다. 이전에는 각 제품마다 별도의 Git 저장소를 가졌습니다(멀티레포). 하지만 제품군이 10개를 넘어가기 시작하면 치명적인 문제들이 발생합니다. - 코드 중복과 파편화 : 로그인을 처리하는 로직을 A 레포에도, B 레포에도 복사해서 붙여넣습니다.

마이크로 프론트엔드 아키텍처는 다음 네 가지 핵심 원칙 위에 세워집니다. 1.1 기술 독립성 (Technology Agnostic) 각 마이크로 프론트엔드 팀은 자신만의 기술 스택을 자유롭게 선택할 수 있어야 합니다. A 팀은 React로, B 팀은 Vue로, C 팀은 Svelte로 개발하더라도 최종 사용자에게는 하나의 매끄러운 애플리케이션으로 보여야 합니