- Transactional Outbox (트랜잭셔널 아웃박스)Transactional Outbox는 DB에 데이터를 저장하는 일과 메시지 브로커에 이벤트를 발행하는 일을 확실하게 함께 처리하기 위해, 이벤트를 먼저 같은 DB의 "보낼 편지함(outbox) 테이블"에 같은 트랜잭션으로 저장해 두고 별도의 프로세스가 그 테이블을 읽어 브로커로 보내는 패턴입니다.아키텍처·2026.10.02 · architecture, backend
- Saga Pattern (사가 패턴)Saga는 여러 서비스(또는 여러 Aggregate)에 걸친 하나의 업무 흐름을 각자의 로컬 트랜잭션들의 연속으로 나누고, 중간에 실패하면 이미 완료된 단계들을 "보상 트랜잭션"으로 되돌리는 패턴입니다. 1987년 헥터 가르시아-몰리나(Hector Garcia-Molina)와 케네스 세일럼(Kenneth Salem)의 논문에서 처음 소개되었습니다.아키텍처·2026.10.02 · architecture, backend
- Onion Architecture (어니언 아키텍처)Onion Architecture는 제프리 팔레르모(Jeffrey Palermo)가 2008년 블로그 연재 글로 제안한 구조입니다. 애플리케이션을 양파처럼 여러 겹의 동심원 계층으로 나누고, 가장 안쪽에 도메인 모델을 둡니다.아키텍처·2026.10.02 · architecture, backend
- Layered vs Hexagonal vs Onion vs Clean Architecture가장 중요한 차이는 표의 네 번째 줄입니다. Layered만 비즈니스가 DB 쪽을 향해 의존하고, 나머지 셋은 모두 그 방향을 뒤집었습니다. Hexagonal, Onion, Clean은 같은 아이디어를 다르게 그린 것에 가깝습니다.아키텍처·2026.10.02 · architecture, backend
- Layered Architecture (계층형 아키텍처)Layered Architecture는 애플리케이션을 역할별 계층(Layer)으로 나누고, 위 계층이 바로 아래 계층만 사용하도록 만든 구조입니다. 백엔드에서 가장 흔하게 볼 수 있는 구조이고, Nest.js나 Spring으로 프로젝트를 만들면 대부분 자연스럽게 이 모양이 됩니다.아키텍처·2026.10.02 · architecture, backend
- Hexagonal Architecture (헥사고날 아키텍처)Hexagonal Architecture는 비즈니스 로직(애플리케이션 핵심)을 가운데 두고, DB·HTTP·메시지 큐 같은 외부 기술은 모두 바깥에 두어 "포트(Port)"와 "어댑터(Adapter)"로만 연결하는 구조입니다. 2005년 앨리스터 코오번(Alistair Cockburn)이 제안했고, 정식 이름은 Ports and Adapters입니다.아키텍처·2026.10.02 · architecture, backend
- Event Sourcing (이벤트 소싱)Event Sourcing은 현재 상태를 저장하는 대신, 상태를 바꾼 사건(이벤트)을 순서대로 모두 저장하고, 현재 상태는 이벤트를 처음부터 다시 재생해서 만들어 내는 방식입니다.아키텍처·2026.10.02 · architecture, backend
- Event-Driven Architecture (이벤트 기반 아키텍처)Event-Driven Architecture(EDA)는 컴포넌트들이 서로를 직접 호출하지 않고, "무슨 일이 일어났다"는 이벤트를 발행하고 구독하는 방식으로 협력하는 구조입니다.아키텍처·2026.10.02 · architecture, backend
- DDD (Domain-Driven Design, 도메인 주도 설계)DDD(Domain-Driven Design)는 소프트웨어의 구조와 언어를 실제 비즈니스(도메인)에 맞추는 설계 방법입니다. 2003년 에릭 에반스(Eric Evans)의 책 *Domain-Driven Design*에서 정리되었습니다.아키텍처·2026.10.02 · architecture, backend, ddd
- DDD 전술 설계 (Tactical Design)전술 설계는 전략 설계로 나눈 하나의 Bounded Context 안에서, 도메인 규칙을 코드로 어떻게 표현할지 정하는 패턴 모음입니다.아키텍처·2026.10.02 · architecture, backend, ddd
- DDD 전략 설계 (Strategic Design)전략 설계는 DDD에서 시스템을 어떤 기준으로 나누고, 나눈 조각들이 서로 어떻게 관계를 맺을지 정하는 단계입니다. 클래스 하나하나를 어떻게 만들지는 다루지 않습니다. 그건 전술 설계의 몫입니다.아키텍처·2026.10.02 · architecture, backend, ddd
- Aggregate (애그리거트)Aggregate는 데이터 변경의 단위로 함께 다뤄야 하는 객체들의 묶음입니다. 묶음 바깥에서는 대표 객체 하나, 즉 Aggregate Root를 통해서만 안쪽 객체에 접근할 수 있습니다.아키텍처·2026.10.02 · architecture, backend, ddd
- CQRS (Command Query Responsibility Segregation)CQRS(Command Query Responsibility Segregation)는 데이터를 바꾸는 일(Command)과 데이터를 읽는 일(Query)을 서로 다른 모델로 분리하는 패턴입니다. 2010년 무렵 그렉 영(Greg Young)이 이름 붙이고 널리 알렸습니다.아키텍처·2026.10.02 · architecture, backend
- Clean Architecture (클린 아키텍처)Clean Architecture는 로버트 C. 마틴(Robert C. Martin, 흔히 "엉클 밥")이 2012년 블로그 글로 소개하고, 2017년 책 *Clean Architecture*로 정리한 소프트웨어 구조입니다.아키텍처·2026.10.02 · architecture, backend
- 백엔드 아키텍처 선택 가이드지금까지 살펴본 패턴들은 서로 대체재가 아닙니다. 각자 다른 질문에 답하기 때문에 함께 조합해서 씁니다. 이 문서는 각 패턴이 어떤 질문에 답하는지 정리하고, 상황에 따라 무엇을 얼마나 적용할지 고르는 기준을 제시합니다.아키텍처·2026.10.02 · architecture, backend
찾는 내용이 없다면 직접 물어보세요
프로젝트와 블로그 글에서 답을 찾습니다