Layered Architecture

Layered Architecture

계층형 아키텍처 (Layered Architecture) 는 각 역할, 책임, 처리 흐름을 명확히 구분하여 복잡한 소프트웨어 시스템을 논리적 계층으로 나누는 구조적 설계 패턴이다.

전통적인 계층 구조는 단방향 흐름과 명확한 책임 분리를 중심으로 단순성과 빠른 개발 속도를 중시했던 아키텍처다. 하지만 시간이 지나며 계층 간 강한 결합, 테스트의 어려움, 확장성 제약 등의 한계가 드러났고, 특히 계층 간 통신 비용 증가, 변경 시 여러 계층에 걸친 리팩토링 요구, 단단한 결합, 병렬 처리의 어려움 등도 함께 고려해야 할 구조적 문제로 지적되고 있다.

이러한 한계를 보완하기 위해 등장한 현대적 계층 구조는 동적 재구성, 레이어 간 의존성 최소화, 서비스 기반 접근법, DevOps 자동화 등 최신 개발 환경과 요구의 변화에 유연하게 적응하며, 유지보수성과 확장성을 극대화한다. 특히 도메인 중심의 Hexagonal Architecture, Onion Architecture, Clean Architecture 와 같은 계층화 모델은 테스트 용이성과 변경 유연성을 확보하는 데 효과적이며, 마이크로서비스, DDD, CI/CD 기반 DevOps 환경과도 높은 시너지를 발휘한다.

등장 배경 및 발전 과정

메인프레임 시대와 계층형 사고의 출현 (1950 년대~1970 년대)

초기 컴퓨팅 환경의 특징

• 메인프레임 중심의 컴퓨팅:
  • IBM System/360 (1964): 최초의 계층적 시스템 구조 도입
  • 배치 처리 시스템: 펀치카드와 자기 테이프를 통한 입력 처리
  • 중앙집중식 아키텍처: 모든 처리가 메인프레임에서 수행
  • 터미널 시스템: 더미 터미널을 통한 사용자 인터페이스

메인프레임 중심의 컴퓨팅 (Mainframe-Centric Computing)
메인프레임 (Mainframe) 은 대량의 데이터 처리, 고가용성, 보안성, 안정성이 요구되는 기업 또는 기관의 핵심 업무 시스템을 수행하기 위해 설계된 대형 중앙 집중식 컴퓨터 시스템이다. 메인프레임 중심 컴퓨팅은 이러한 메인프레임을 업무 처리의 핵심 허브로 삼아 모든 처리를 중앙화된 방식으로 수행하는 컴퓨팅 모델이다.

1950 년대 초기 컴퓨터 시스템의 문제점:

• 하드웨어 직접 제어: 프로그래머가 CPU 명령어, 메모리 주소, I/O 포트를 직접 다뤄야 함
• 중복 개발: 모든 프로그램이 기본적인 I/O 처리를 반복 구현
• 하드웨어 의존성: 다른 컴퓨터로 프로그램 이식 시 전체 재작성 필요
• 복잡성 폭발: 시스템이 커질수록 관리 불가능한 복잡도

계층화를 통한 문제 해결:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

┌─────────────────┐  ← 문제 해결: 사용자가 복잡한 명령어 외울 필요 없음
│  User Terminal  │    → 표준화된 명령어 인터페이스 제공
├─────────────────┤
│  Job Control    │  ← 문제 해결: 작업 스케줄링과 자원 관리 자동화
│                 │    → 배치 작업 순서, 우선순위, 자원 할당 관리
├─────────────────┤
│  Application    │  ← 문제 해결: 비즈니스 로직과 시스템 로직 분리
│                 │    → 개발자는 하드웨어 걱정 없이 애플리케이션 로직에 집중
├─────────────────┤
│  Operating Sys  │  ← 문제 해결: 하드웨어 추상화 및 공통 서비스 제공
│                 │    → 파일 시스템, 메모리 관리, 프로세스 관리 표준화
├─────────────────┤
│  Hardware       │  ← 문제 해결: 물리적 자원의 직접 접근 차단
└─────────────────┘    → 안전하고 효율적인 하드웨어 사용

1. 추상화 (Abstraction):
   계층화 도입 이전에는 프로그래머가 직접 하드웨어 명령어를 작성지만 이후에는 프로그래머는 운영체제 함수만 작성하면 운영체제가 하드웨어 명령어로 반환이 가능하다.
2. 관심사의 분리 (Separation of Concerns):
   각 계층마다 전문적으로 담당하는 영역이 다르다.
3. 재사용성과 이식성:
   하드웨어 변경시, 계층화 이전에는 전체를 재작성해야 했지만 이후에는 하드웨어 추상화 계층만 수정하면 된다.

현대 소프트웨어 계층화의 뿌리: 메인프레임 계층화 → 현대 아키텍처 연결

graph TD
    subgraph "1960s 메인프레임"
        A1[User Terminal]
        A2[Job Control]
        A3[Application]
        A4[Operating System]
        A5[Hardware]
    end
    
    subgraph "현대 웹 애플리케이션"
        B1[Web Browser]
        B2[Web Server]
        B3[Application Server]
        B4[Database Server]
        B5[Infrastructure]
    end
    
    A1 -.->|진화| B1
    A2 -.->|진화| B2
    A3 -.->|진화| B3
    A4 -.->|진화| B4
    A5 -.->|진화| B5

전통적 Layered Architecture 의 확립 (1980 년대~1990 년대)

클라이언트 - 서버 모델의 등장

2-Tier Architecture (1980 년대):

• PC 의 보급: 개인용 컴퓨터가 더미 터미널을 대체
• 분산 처리: 처리 능력이 클라이언트와 서버로 분산
• 네트워크 컴퓨팅: LAN 기술의 발전으로 가능해진 분산 아키텍처

기술적 동력:

• 관계형 데이터베이스: Oracle, IBM DB2, SQL Server 등의 상용화
• 네트워킹 기술: TCP/IP 프로토콜 표준화
• GUI 기술: Windows, Mac OS 의 그래픽 사용자 인터페이스

3-Tier Architecture 의 표준화 (1990 년대)

웹 기술의 영향:

• World Wide Web (1991): 브라우저 - 웹서버 - 데이터베이스 구조
• HTTP 프로토콜: 무상태 (stateless) 통신 방식
• 인터넷 확산: 전 세계적인 네트워크 연결

표준 3 계층 구조:

graph TD
    A[Presentation Layer<br/>웹 브라우저, GUI] --> B[Application Layer<br/>웹 서버, 비즈니스 로직]
    B --> C[Data Layer<br/>데이터베이스, 파일 시스템]
    
    A1[사용자 인터페이스] --> B1[비즈니스 규칙 처리]
    B1 --> C1[데이터 저장 및 관리]

엔터프라이즈 표준의 확립 (2000 년대 초기)

J2EE (Java 2 Platform, Enterprise Edition) 영향:

• 컨테이너 기반: EJB 컨테이너, 서블릿 컨테이너
• 선언적 서비스: 트랜잭션, 보안, 네이밍 서비스
• 표준화: 업계 전반의 아키텍처 표준 확립

.NET Framework 의 기여:

• ASP.NET: 웹 애플리케이션 개발 표준화
• Windows DNA: Distributed interNet Architecture
• COM+: 컴포넌트 기반 서비스

전통적 아키텍처의 한계와 문제점 인식 (2000 년대)

구조적 문제점들

긴밀한 결합 (Tight Coupling):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// 긴밀한 결합의 예시
public class OrderService {    
    private MySQLOrderDAO orderDAO = new MySQLOrderDAO(); // 구체 클래스에 직접 의존
    
    public void createOrder(Order order) {
        // MySQL 특정 로직에 의존
        orderDAO.saveWithTransaction(order); // MySQL 트랜잭션 방식에 종속
    }
}

// 문제: MySQL → PostgreSQL 변경 시
// OrderService까지 수정해야 함 (의존성 전파)

주요 문제점들:

• 의존성 전파: 하위 계층 변경이 상위 계층에 영향
  • Database Schema 변경 → DAO 변경 → Service 변경 → Controller 변경 → View 변경
• 테스트 어려움: 데이터베이스 없이 비즈니스 로직 테스트 불가
  • 테스트를 위해 실제 DB 설정, 테스트 데이터 준비 등이 필요
• 기술 종속성: 특정 데이터베이스나 프레임워크에 강하게 결합
• 단일 책임 원칙 위반: 계층이 여러 책임을 동시에 가짐

비즈니스 요구사항의 변화

복잡성 증가:

• 비즈니스 로직 복잡화: 단순 CRUD 를 넘어선 복잡한 업무 규칙
• 다중 채널: 웹, 모바일, API 등 다양한 인터페이스 요구
• 실시간 처리: 배치 처리에서 실시간 처리로 변화
• 확장성 요구: 대용량 트래픽과 데이터 처리 필요

Domain-Driven Design 의 등장과 패러다임 전환 (2003 년)

Eric Evans 의 혁신적 접근

DDD 의 핵심 통찰:

" 소프트웨어의 핵심은 사용자를 위해 도메인 관련 문제를 해결하는 능력이다. 다른 모든 것들은 부차적이다."

전통적 접근법과의 차이점:

4 계층 구조 제안:

graph TD
    subgraph "DDD 4-Layer Architecture"
        A[User Interface Layer<br/>사용자 인터페이스]
        B[Application Layer<br/>애플리케이션 서비스]
        C[Domain Layer<br/>도메인 모델, 비즈니스 로직]
        D[Infrastructure Layer<br/>데이터 접근, 외부 서비스]
    end
    
    A --> B
    B --> C
    D -.-> C
    D -.-> B
    D -.-> A

• 기본 원칙:
  • 의존성 규칙: 각 계층은 자신보다 아래 계층에만 의존 가능
  • Domain Layer 격리: 도메인 계층은 완전히 격리되어 다른 계층에 의존하지 않음
  • Infrastructure Layer 특성: 모든 계층을 지원하되, 계층들이 Infrastructure 에 의존하지 않도록 역전된 의존성 적용
• 핵심 설계 원칙
  1. Domain Layer 보호: 가장 중요한 비즈니스 로직이 외부 변화로부터 격리
  2. 의존성 역전: Infrastructure 가 Domain 인터페이스를 구현
  3. 관심사의 분리: 각 계층이 명확한 단일 책임을 가짐
  4. 테스트 용이성: 각 계층을 독립적으로 테스트 가능

이 4 계층 구조는 전통적인 3 계층 구조의 문제점 (비즈니스 로직 분산, 기술 종속성) 을 해결하고, 도메인 중심의 설계를 가능하게 하는 Eric Evans 의 핵심 기여이다.

계층 간 통신 흐름:

sequenceDiagram
    participant UI as User Interface
    participant App as Application
    participant Dom as Domain
    participant Infra as Infrastructure

    UI->>App: createOrder(request)
    App->>Dom: Customer.placeOrder(items)
    Dom->>Dom: validate business rules
    Dom-->>App: return Order
    App->>Infra: orderRepository.save(order)
    Infra-->>App: success
    App->>Infra: eventPublisher.publish(event)
    App-->>UI: return OrderDto

계층별 정리:

아키텍처 철학의 변화

도메인 중심 사고:

• 비즈니스 가치 우선: 기술보다 비즈니스 문제 해결에 집중
• 도메인 전문가와의 협업: 개발자와 비즈니스 사이의 언어 통일
• 점진적 학습: 도메인 이해가 깊어질수록 모델을 개선

Service-Oriented Architecture (SOA) 의 발전 (2000 년대 중반)

SOA 의 등장 배경

기업 환경의 변화:

• 레거시 시스템 통합: 다양한 시스템들의 상호 운용성 필요
• 비즈니스 민첩성: 빠른 비즈니스 변화에 대응
• 재사용성 요구: 중복 개발 비용 절감

SOA 핵심 원칙:

1. 서비스 지향 (Service Orientation)

   1 2	비즈니스 기능을 독립적인 서비스로 분리 예: 고객 관리, 주문 처리, 결제 처리를 각각 별도 서비스로

2. 느슨한 결합 (Loose Coupling)

   1 2	서비스 간 최소한의 의존성으로 독립성 확보 예: 주문 서비스가 고객 서비스의 내부 구현을 알 필요 없음

3. 서비스 재사용성 (Service Reusability)

   1 2	한번 만든 서비스를 여러 애플리케이션에서 재사용 예: 고객 정보 서비스를 웹사이트, 모바일앱, 콜센터에서 공통 사용

4. 서비스 계약 (Service Contract)

   1 2	명확한 인터페이스 정의로 서비스 사용 방법 표준화 예: WSDL을 통한 서비스 명세서 제공

5. 서비스 추상화 (Service Abstraction)

   1 2	서비스 내부 구현 숨기고 인터페이스만 노출 예: 데이터베이스 변경되어도 서비스 인터페이스는 동일

6. 서비스 조합성 (Service Composability)

   1 2	여러 서비스를 조합하여 복잡한 비즈니스 프로세스 구현 예: 주문 = 고객 조회 + 재고 확인 + 결제 처리 + 배송 요청

ESB (Enterprise Service Bus) 의 도입

중앙집중식 통합:

• 메시지 라우팅: 서비스 간 통신 중재
• 프로토콜 변환: 다양한 통신 프로토콜 지원
• 서비스 검색: 동적 서비스 발견 및 바인딩

SOA 의 한계:

• 복잡성 증가: ESB 가 단일 장애점 (SPOF) 이 됨
• 성능 오버헤드: 중앙 집중식 처리로 인한 지연
• 거버넌스 어려움: 서비스 간 의존성 관리 복잡

현대적 아키텍처 패턴의 등장 (2005 년~2012 년)

Hexagonal Architecture (2005 년)

Alistair Cockburn 의 혁신:

• 포트와 어댑터: 외부 세계와의 인터페이스 추상화
• 비즈니스 로직 격리: 핵심 로직을 외부 의존성으로부터 분리
• 테스트 용이성: 실제 외부 시스템 없이도 테스트 가능

graph TD
    subgraph "Hexagonal Architecture"
        subgraph "Adapters (외부)"
            A1[Web UI]
            A2[REST API]
            A3[Database]
            A4[Message Queue]
        end
        
        subgraph "Ports (인터페이스)"
            P1[Inbound Ports]
            P2[Outbound Ports]
        end
        
        subgraph "Core (비즈니스 로직)"
            C[Domain Logic]
        end
        
        A1 --> P1
        A2 --> P1
        P1 --> C
        C --> P2
        P2 --> A3
        P2 --> A4
    end

Onion Architecture (2008 년)

Jeffrey Palermo 의 기여:

• 동심원 구조: 의존성이 중심을 향해 흐름
• 계층의 명확한 정의: 각 계층의 역할과 책임 명시
• 인프라스트럭처 분리: 외부 관심사를 가장 바깥 계층으로

Clean Architecture (2012 년)

Robert Martin (Uncle Bob) 의 통합:

• 의존성 규칙: " 소스 코드 의존성은 안쪽으로만 향해야 한다 "
• 경계의 명확화: 각 계층 간 명확한 경계와 계약 정의
• 플러그인 아키텍처: 프레임워크와 도구를 플러그인으로 취급

graph TD
    subgraph "Clean Architecture"
        subgraph "Frameworks & Drivers"
            F1[Web Frameworks]
            F2[Database]
            F3[External Interfaces]
        end
        
        subgraph "Interface Adapters"
            I1[Controllers]
            I2[Gateways]
            I3[Presenters]
        end
        
        subgraph "Application Business Rules"
            A[Use Cases]
        end
        
        subgraph "Enterprise Business Rules"
            E[Entities]
        end
        
        F1 --> I1
        F2 --> I2
        F3 --> I3
        I1 --> A
        I2 --> A
        I3 --> A
        A --> E
    end

마이크로서비스 아키텍처의 부상 (2010 년대)

클라우드 컴퓨팅의 영향

기술적 기반:

• 컨테이너화: Docker (2013), Kubernetes (2014)
• 클라우드 플랫폼: AWS, Azure, Google Cloud Platform
• DevOps 문화: 지속적 통합/배포 (CI/CD)

MSA 의 핵심 특징

SOA 와의 차이점:

현대적 계층형 아키텍처의 특징 (2010 년대~현재)

의존성 역전 원칙 (DIP) 적용

전통적 방식 vs 현대적 방식:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 전통적 방식 (문제가 있는 코드)
class OrderService:
    def __init__(self):
        self.db = MySQLDatabase()  # 구체 클래스에 의존
        self.email = SMTPEmailService()  # 구체 클래스에 의존
    
    def process_order(self, order):
        self.db.save(order)
        self.email.send_confirmation(order.customer_email)

# 현대적 방식 (의존성 역전 적용)
class OrderService:
    def __init__(self, repository: OrderRepository, email_service: EmailService):
        self.repository = repository  # 추상화에 의존
        self.email_service = email_service  # 추상화에 의존
    
    def process_order(self, order):
        self.repository.save(order)
        self.email_service.send_confirmation(order.customer_email)

이벤트 기반 아키텍처 통합

비동기 처리와 이벤트 소싱:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 현대적 이벤트 기반 처리
class OrderService:
    def __init__(self, event_publisher: EventPublisher):
        self.event_publisher = event_publisher
    
    def process_order(self, order):
        # 도메인 이벤트 발생
        event = OrderCreatedEvent(
            order_id=order.id,
            customer_id=order.customer_id,
            amount=order.total_amount
        )
        
        # 이벤트 발행 (다른 서비스들이 비동기로 처리)
        self.event_publisher.publish(event)

클라우드 네이티브 특성

현대적 배포와 확장:

• 컨테이너 오케스트레이션: Kubernetes 기반 자동 확장
• 서비스 메시: Istio, Linkerd 를 통한 서비스 간 통신 관리
• 관찰가능성: 분산 추적, 메트릭, 로깅 통합
• 복원력: Circuit Breaker, Bulkhead 패턴 적용

진화의 핵심 동력과 개선사항

기술적 동력

1960 년대 → 현재까지의 기술 발전:

1
2
3

메인프레임 → 클라이언트-서버 →   웹   → SOA     → 클라우드 → 마이크로서비스
     ↓            ↓           ↓      ↓           ↓           ↓
배치처리   →   대화형처리   →  HTTP → XML/SOAP →  REST   →   컨테이너

주요 개선사항

전통적 → 현대적 전환:

미래 방향성

2020 년대 이후 트렌드:

• 서버리스 아키텍처 (Serverless Architecture) 와 계층 구조의 융합
  서버리스 컴퓨팅 (Serverless Computing) 기반 환경에서는 계층형 아키텍처의 일부 계층 (예: 프리젠테이션, 비즈니스 로직 계층 등) 을 함수 (Function) 단위로 더 유연하게 분리하고 확장함. 이로 인해 기존 계층 구조의 고정성과 배포 단위를 혁신적으로 변화시키며, 이벤트 중심 처리도 손쉽게 확장할 수 있게 됨.

• 멀티테넌트 (Multi-Tenant) 환경에 최적화된 계층 설계
  SaaS(Software as a Service) 서비스 등 멀티테넌시 (Multi-Tenancy) 가 필요한 시스템에서는 데이터 액세스 계층과 도메인 계층에 개별 테넌트 분리를 적용하여 확장성과 보안성을 강화함.

• AI 자동화 연계
  계층별 AI 모듈 (예: 추천, 예측, 자동 모니터링) 이 삽입됨으로써, 특정 계층 (예: 서비스 계층, 프리젠테이션 계층) 에서 사용자의 행동 또는 상황에 적응하는 자동화 로직을 손쉽게 통합할 수 있음.

• 유연한 계층 전환 및 조합:
  시스템 요구에 따라 레이어의 수와 역할을 동적으로 조절할 수 있는 패턴과 도구의 필요성이 높아짐.

• 자동화 도구 및 오케스트레이션 연계:
  IaC(Infrastructure as Code, 코드 기반 인프라 자동화), 컨테이너 오케스트레이션 (Kubernetes 등) 과의 통합이 필수화.

• 신속한 장애 복구 및 모니터링:
  계층별 장애 감지 및 롤백 전략 (A/B 테스트, Canary 배포 등) 정교화 필요.

계층형 아키텍처와 다른 아키텍처 패턴과의 비교

목적 및 필요성

Layered Architecture 는 시스템의 복잡성을 기능적 책임에 따라 계층화함으로써 구조적 명확성과 유지보수성을 극대화하는 설계 전략이다. 하지만 시대적 변화와 비즈니스 요구사항의 진화에 따라 그 목적과 접근법이 크게 달라졌다.

공통 목적

전통적 접근법의 목적 및 필요성 (1990 년대~2000 년대)

등장 배경:

• 클라이언트 - 서버 시대의 도래: 단일 머신 환경에서 분산 환경으로의 전환
• 데이터베이스 중심 사고: RDBMS 의 보편화로 데이터 저장소가 시스템의 핵심으로 인식
• 기술적 복잡성 관리: UI, 비즈니스 로직, 데이터 접근의 기술적 분리 필요성

핵심 목적:

필요성의 한계:

• 데이터베이스 의존성: 비즈니스 로직이 데이터베이스 스키마에 강하게 결합
• 하향식 의존성: 상위 계층 변경이 하위 계층까지 영향을 미치는 구조적 문제
• 모놀리식 제약: 전체 시스템이 하나의 배포 단위로 관리되어 확장성 제한

현대적 접근법의 목적 및 필요성 (2000 년대~현재)

등장 배경:

• 비즈니스 복잡성 증가: 단순한 CRUD 를 넘어선 복잡한 도메인 로직 처리 필요
• 클라우드 네이티브 환경: 마이크로서비스, 컨테이너화, DevOps 문화의 확산
• 지속적 변화 대응: 애자일 개발과 빠른 비즈니스 요구사항 변화에 대한 대응
• 테스트 중심 개발: TDD, BDD 등 테스트 가능한 아키텍처의 중요성 증대

핵심 목적:

현대적 필요성:

접근법별 비교 분석

전통적 Layered Architecture 는 기술적 복잡성 관리에 중점을 둔 반면, 현대적 접근법은 비즈니스 복잡성 관리와 변화 대응성에 중점을 둔다. 이러한 패러다임 전환은 단순한 기술적 진화가 아니라, 소프트웨어가 비즈니스에 미치는 영향력 증대와 시장 환경의 급격한 변화에 대한 필연적 대응이라 할 수 있다.

따라서 현대의 소프트웨어 아키텍트는 프로젝트의 복잡성, 변화 빈도, 팀 구성, 비즈니스 목표 등을 종합적으로 고려하여 적절한 접근법을 선택해야 한다.

핵심 개념

Layered Architecture 는 관심사의 분리 (Separation of Concerns) 를 통해 시스템 복잡성을 체계적으로 관리하는 아키텍처 설계 철학이다. 시대적 변화에 따라 기술 중심에서 도메인 중심으로 패러다임이 전환되면서 핵심 개념과 실무 적용 방식이 크게 진화했다.

계층 (Layer) vs. 티어 (Tier) 개념 정립

핵심: Layer 는 설계상의 추상화, Tier 는 배포 관점의 구분이며, 하나의 Tier 에 여러 Layer 가 존재할 수 있다.

전통적 Layered Architecture 핵심 개념

전통적 핵심 개념 상세

1. 계층별 기술적 책임 분리 (Technical Layer Responsibility)

   1 2 3 4 5 6 7 8 9

   ┌─────────────────────────────────────┐ │ Presentation Layer (UI/Controller) │ ← 사용자 인터페이스 처리 ├─────────────────────────────────────┤ │ Business Layer (Service/Logic) │ ← 비즈니스 규칙 실행 ├─────────────────────────────────────┤ │ Persistence Layer (Repository/DAO) │ ← 데이터 접근 추상화 ├─────────────────────────────────────┤ │ Database Layer (RDBMS) │ ← 데이터 저장소 └─────────────────────────────────────┘

2. 폐쇄 계층 (Closed Layer) 원칙

   • 요청은 모든 계층을 순차적으로 통과해야 함
   • 계층 건너뛰기 방지로 격리성 보장
   • 각 계층의 책임 명확화

3. 개방 계층 (Open Layer) 예외

   • 아키텍처 싱크홀 안티패턴 방지
   • 부가가치 없는 계층 우회 허용
   • 성능 최적화를 위한 직접 접근

현대적 Domain-Centric Architecture 핵심 개념

현대적 핵심 개념 상세

1. 도메인 중심성 (Domain Centricity)

   1 2 3 4 5 6 7 8 9 10

   ┌─────────────────────────────────┐ │ Infrastructure Layer │ │ ┌─────────────────────────┐ │ │ │ Application Layer │ │ │ │ ┌─────────────────┐ │ │ │ │ │ Domain Layer │ │ │ ← 비즈니스 로직 중심 │ │ │ (Entities, VOs) │ │ │ │ │ └─────────────────┘ │ │ │ └─────────────────────────┘ │ └─────────────────────────────────┘

2. 의존성 역전 원칙 (Dependency Inversion Principle)

   • 전통적: UI → Business → Data → Database
   • 현대적: Infrastructure → Application → Domain (중심)
   • 고수준 모듈이 저수준 모듈의 추상화에 의존

3. 포트와 어댑터 (Ports and Adapters)

   • 포트 (Ports): 도메인이 정의하는 인터페이스
   • 어댑터 (Adapters): 외부 시스템과의 구체적 연결
   • 플러그인 가능한 아키텍처 구현

실무 연관성 및 구현 전략

전통적 접근법의 실무 연관성

현대적 접근법의 실무 연관성

현대적 아키텍처 패턴과의 연관성

1. Clean Architecture 와의 관계

   • 의존성 규칙: 외부 계층이 내부 계층에 의존
   • 엔터프라이즈 비즈니스 규칙: 도메인 엔티티
   • 애플리케이션 비즈니스 규칙: 유스케이스

2. Hexagonal Architecture 와의 관계

   • 헥사곤 (애플리케이션 코어): 비즈니스 로직
   • 포트: 애플리케이션과 외부 세계 간의 인터페이스
   • 어댑터: 특정 기술에 대한 구현체

3. Onion Architecture 와의 관계

   • 도메인 모델: 최내부 계층
   • 도메인 서비스: 도메인 로직 포함
   • 애플리케이션 서비스: 유스케이스 조정
   • 인프라스트럭처: 외부 계층

핵심 개념 비교 분석

설계 철학 차이

실무에서의 혼합 접근법

전통적인 Layered Architecture 의 구조적 명확성과 현대적인 Domain-Centric 아키텍처의 유연성과 테스트 용이성을 결합하여 사용하는 것이 효과적이다.

이 방식은 **도메인 중심 설계 (DDD)**를 중심 코어로 두고, 그 외부는 전통적 계층처럼 Presentation, Persistence, Integration 계층으로 나누는 구조를 취한다. 이로써 비즈니스 로직의 독립성과 재사용성을 확보하면서도, 개발자와 인프라 팀에게 익숙한 레이어드 구조를 유지할 수 있다.

하이브리드 아키텍처 구조

• Core (도메인 중심 구조)

  • Domain Layer: Entity, Value Object, Domain Logic
  • Application Layer: Use Case, Application Service

• Infrastructure (전통적 구조 적용)

  • Presentation Layer: REST Controller, GraphQL Resolver 등
  • Persistence Layer: Repository Implementation (e.g., JPA, ORM)
  • Integration Layer: 외부 API, 메시지 브로커 어댑터

graph TD

subgraph "Presentation Layer"
    UI[REST Controller / UI Adapter]
end

subgraph "Application Layer (Use Cases)"
    UC[Use Case / Application Service]
end

subgraph "Domain Layer"
    E[Entities]
    V[Value Objects]
    S[Domain Services]
end

subgraph "Infrastructure Layer"
    DB["Repository Implementation (JPA/ORM)"]
    EXT[External API Client]
    MSG[Message Queue Adapter]
end

UI --> UC
UC --> S
UC --> E
UC --> V
S --> E
S --> V

DB -.-> UC
EXT -.-> UC
MSG -.-> UC

DB -->|implements| RepoPort[Persistence Port]
EXT -->|implements| APIClientPort[API Port]
MSG -->|implements| MessagePort[Event Port]

RepoPort --> UC
APIClientPort --> UC
MessagePort --> UC

• **Use Case 계층 (Application Layer)**는 도메인 계층을 호출하면서 외부 시스템 (Infra) 을 직접 의존하지 않고 Port 인터페이스를 통해 접근한다.
• Infrastructure Layer는 전통적인 방식대로 기술 기반 컴포넌트를 구현하지만, 인터페이스를 구현하는 방식으로 DIP(Dependency Inversion Principle) 를 만족한다.
• Domain Layer는 외부 의존이 없는 순수한 비즈니스 로직만 포함한다.

주요 기능 및 역할

전통적 vs. 현대적 Layered Architecture 비교

전통적 계층별 기능 및 역할

의존성 방향: Presentation → Business → Persistence → Database (하향식)

현대적 계층별 기능 및 역할

의존성 방향: Infrastructure → Application → Domain (중심 지향)

각 계층의 구체적 책임

• Presentation Layer: 시스템 외부와의 접점 → 사용자 및 클라이언트와 통신
• Application Layer: Use Case 중심 흐름 → 도메인 모델을 조정, 외부 인터페이스를 추상화
• Domain Layer: 시스템의 핵심 → 순수한 비즈니스 로직과 규칙을 담당
• Infrastructure Layer: 외부 세계와 통신 → 기술 세부사항 및 외부 리소스 연동

계층 간 상호작용 패턴

전통적 상호작용

sequenceDiagram
    participant UI as Presentation
    participant BL as Business Logic
    participant DAL as Data Access
    participant DB as Database
    
    UI->>BL: processRequest(data)
    BL->>BL: validateBusinessRules(data)
    BL->>DAL: saveData(processedData)
    DAL->>DB: INSERT/UPDATE
    DB-->>DAL: result
    DAL-->>BL: savedData
    BL-->>UI: response

현대적 상호작용

sequenceDiagram
    participant P as Presentation
    participant A as Application
    participant D as Domain
    participant I as Infrastructure
    
    P->>A: executeUseCase(request)
    A->>D: createDomainObject(data)
    D->>D: applyBusinessRules()
    A->>I: persist(domainObject)
    I->>I: mapToDatabase()
    I-->>A: persistedObject
    A-->>P: response

공통 횡단 관심사 (Cross-cutting Concerns)

특징

Layered Architecture 는 구조적 명확성과 운영 효율성을 동시에 추구하는 아키텍처 패턴이다. 수평적 계층 구분, 단방향 의존성, 관심사의 분리를 통해 유지보수성과 확장성을 확보하고, 각 계층의 역할과 책임을 인터페이스 기반으로 독립화함으로써 테스트 용이성, 배포 독립성, 팀별 협업, 모듈화의 장점을 극대화한다.

구조적 특징

동작적 특징

전통적 Layered Architecture

graph TD
    A[Presentation Layer] --> B[Business Layer]
    B --> C[Persistence Layer] 
    C --> D[Database Layer]
    
    A1[HTTP Request] --> B1[Service Logic]
    B1 --> C1[Data Access]
    C1 --> D1[SQL Database]

특징:

• 순차적 처리: 요청이 모든 계층을 순차적으로 통과
• 폐쇄 계층: 각 계층을 반드시 거쳐야 함
• 동기적 통신: 계층 간 동기식 호출 방식

현대적 Layered Architecture

graph TD
    subgraph "Infrastructure Layer"
        A[REST Controllers]
        B[Database Adapters]
        C[Message Brokers]
    end
    
    subgraph "Application Layer"
        D[Use Cases]
        E[Application Services]
    end
    
    subgraph "Domain Layer"
        F[Domain Entities]
        G[Domain Services]
        H[Business Rules]
    end
    
    A --> D
    B -.-> D
    C -.-> D
    D --> F
    E --> G
    F --> H

특징:

• 비동기 처리: 계층 간 비동기 통신 지원
• 개방/폐쇄 계층: 상황에 따른 계층 우회 허용
• 이벤트 기반: 도메인 이벤트를 통한 느슨한 결합

설계 및 운영 관점 특징

계층별 역할 비교

핵심 원칙

전통적 Layered Architecture 원칙 (1980 년대~2000 년대)

철학적 기반: 기술적 관심사 중심의 분리 (Technology-Centric Separation)

설계 원칙 (Design Principles)

구현 원칙 (Implementation Principles)

현대적 Layered Architecture 원칙 (2000 년대~현재)

철학적 기반: 도메인 중심의 분리 (Domain-Centric Separation)

설계 원칙 (Architectural Design Principles)

구현 원칙 (Implementation & Operational Principles)

패러다임의 전환

graph LR
    subgraph "전통적 접근법"
        A[UI Layer] --> B[Business Layer]
        B --> C[Data Layer]
        C --> D[Database]
    end
    
    subgraph "현대적 접근법"
        E[Infrastructure] --> F[Application]
        F --> G[Domain]
        H[UI] --> F
        I[Database] --> F
    end
    
    A -.evolution.-> H
    B -.evolution.-> F
    C -.evolution.-> I
    D -.evolution.-> I

주요 변화점

통합된 핵심 원칙

아키텍처 설계 원칙 (Architecture Design Principles)

구현 운영 원칙 (Implementation & Operational Principles)

주요 원리 및 작동 원리

전통적 Layered Architecture 작동 원리

• 와이어링 방식: 프레젠테이션 → 비즈니스 → 데이터 액세스 층 순서로 호출 흐름이 내려감. 단순하지만 BLL 이 DAL 구현에 직접 노출됨
• 표준 구성: UI / BLL (Business Logic Layer) / DAL (Data Access Layer) 구조가 일반적
• 테스트 어려움: BLL 테스트 시 실제 DB 없이는 정상적인 검증 어려움, 테스트 환경 구성 복잡

graph TD
    A[Presentation Layer] --> B[Business Layer]
    B --> C[Persistence Layer]
    C --> D[Database Layer]
    
    A1[Controller] --> B1[Service]
    B1 --> C1[Repository]
    C1 --> D1[Database]

작동 방식:

1. 사용자 요청이 Presentation Layer 로 진입
2. Business Layer 에서 비즈니스 로직 처리
3. Persistence Layer 를 통한 데이터 접근
4. Database Layer 에서 데이터 영속성 처리

현대적 Layered Architecture 작동 원리

• 포트 & 어댑터 (Ports & Adapters) 기반 설계: 애플리케이션이 외부와 소통하는 포트는 인터페이스로 정의되고, 이를 구현하는 어댑터를 통해 실제 시스템에 연결됨
• 의존성 반전 (Dependency Inversion Principle): 핵심 비즈니스 로직 (도메인) 은 외부 구현에 의존하지 않으며, 의존은 내부로 향하는 방향만 허용
• 내부 코어 보호: 핵심 도메인 엔티티와 Use Case 는 인프라와 철저히 분리되어 변동에 무관한 안정성 제공

graph TD
    subgraph "Infrastructure Layer"
        A[Web Controllers]
        E[Database Adapters]
        F[External APIs]
    end
    
    subgraph "Application Layer"
        B[Use Cases]
        G[Application Services]
    end
    
    subgraph "Domain Layer"
        C[Entities]
        H[Value Objects]
        I[Domain Services]
    end
    
    A --> B
    B --> C
    B --> H
    B --> I
    E -.-> B
    F -.-> B

작동 방식:

1. 외부 요청이 Infrastructure Layer 의 어댑터로 진입
2. Application Layer 에서 유스케이스 조정
3. Domain Layer 의 비즈니스 객체들이 협업하여 처리
4. Infrastructure Layer 를 통한 외부 시스템 연동

구조 및 아키텍처

전통적 구조

graph TD
    A["Presentation Layer<br/>(Controller, View)"] --> B["Business Layer<br/>(Service, Logic)"]
    B --> C["Data Access Layer<br/>(Repository, DAO)"]
    C --> D["Database Layer<br/>(RDBMS)"]
    B --> E["Integration Layer<br/>(API, Messaging)"]:::optional

    classDef optional fill:#fdf6e3,stroke:#ccc,stroke-dasharray: 5 5;

현대적 구조

graph TD
    subgraph Infrastructure Layer
        INFRA_DB[DB Adapter]
        INFRA_API[External API Adapter]
        INFRA_REPO[Repository Implementation]
        ACL[Anti-Corruption Layer]:::optional
        EVENTS["Event Layer (Publisher/Handler)"]:::optional
    end

    subgraph Application Layer
        USECASE[Use Case]
        APP_SERVICE[Application Service]
    end

    subgraph Domain Layer
        ENTITY[Entities / Value Objects]
        DOMAIN_SERVICE[Domain Services]
    end

    INFRA_DB --> USECASE
    INFRA_API --> USECASE
    INFRA_REPO --> USECASE
    ACL --> USECASE
    EVENTS --> USECASE

    USECASE --> ENTITY
    USECASE --> DOMAIN_SERVICE

    classDef optional fill:#fdf6e3,stroke:#aaa,stroke-dasharray: 5 5;

전통 vs. 현대 Layered Architecture 비교

구현 기법 및 방법

Layered Architecture 의 구현 기법은 시대적 변화와 함께 전통적 접근법에서 현대적 접근법으로 진화해왔다. 이 변화의 핵심은 기술 중심적 설계에서 도메인 중심적 설계로의 패러다임 전환이다.

전통적 Layered Architecture 구현 기법

• 기술적 관심사 중심: 데이터베이스, UI, 비즈니스 로직 등 기술적 요소로 분리
• 하향식 의존성: 상위 계층이 하위 계층에 의존 (UI → Business → Data → Database)
• 데이터베이스 중심 설계: 데이터 모델이 아키텍처의 출발점

구조적 구현 패턴

기본 3-Tier 구조

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 전통적 3계층 구조
src/
├── controllers/          # Presentation Layer
│   ├── UserController.py
│   └── OrderController.py
├── services/            # Business Layer  
│   ├── UserService.py
│   └── OrderService.py
├── repositories/        # Data Access Layer
│   ├── UserRepository.py
│   └── OrderRepository.py
└── models/             # Data Models
    ├── User.py
    └── Order.py

MVC 패턴 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# Controller (Presentation Layer)
class UserController:
    def __init__(self):
        self.user_service = UserService()  # 직접 의존성 생성
    
    def create_user(self, request):
        user_data = request.get_json()
        user = self.user_service.create_user(user_data)
        return {"id": user.id, "name": user.name}

# Service (Business Layer)
class UserService:
    def __init__(self):
        self.user_repository = UserRepository()  # 직접 의존성 생성
    
    def create_user(self, user_data):
        # 간단한 비즈니스 로직
        user = User(user_data['name'], user_data['email'])
        return self.user_repository.save(user)

# Repository (Data Access Layer)
class UserRepository:
    def __init__(self):
        self.db_connection = get_db_connection()  # 직접 DB 연결
    
    def save(self, user):
        # 직접 SQL 실행
        query = "INSERT INTO users (name, email) VALUES (?, ?)"
        self.db_connection.execute(query, (user.name, user.email))
        return user

의존성 관리 방식

직접 의존성 생성

1
2
3
4
5
6

# 전통적 방식: 클래스 내부에서 의존성 직접 생성
class OrderService:
    def __init__(self):
        self.user_repository = UserRepository()      # 강한 결합
        self.product_repository = ProductRepository() # 강한 결합
        self.email_service = EmailService()          # 강한 결합

Factory 패턴 활용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# Factory를 통한 객체 생성
class ServiceFactory:
    @staticmethod
    def create_user_service():
        repository = UserRepository()
        return UserService(repository)
    
    @staticmethod
    def create_order_service():
        user_repo = UserRepository()
        product_repo = ProductRepository()
        return OrderService(user_repo, product_repo)

데이터 처리 방식

직접 데이터 전달

1
2
3
4
5

# 계층 간 도메인 객체 직접 전달
class UserController:
    def get_user(self, user_id):
        user = self.user_service.get_user(user_id)  # 도메인 객체 직접 반환
        return user  # 도메인 노출

Active Record 패턴

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# 데이터와 비즈니스 로직이 혼재
class User:
    def __init__(self, name, email):
        self.name = name
        self.email = email
    
    def save(self):  # 비즈니스 객체가 영속성 책임도 가짐
        db.execute("INSERT INTO users (name, email) VALUES (?, ?)", 
                  (self.name, self.email))
    
    def validate_email(self):  # 비즈니스 로직
        return '@' in self.email

현대적 Layered Architecture 구현 기법

• 도메인 중심 설계: 비즈니스 도메인이 아키텍처의 중심
• 의존성 역전: 외부 계층이 내부 (도메인) 계층에 의존
• 관심사의 명확한 분리: DDD 원칙 적용

현대적 Layered Architecture 는 전통적 접근법의 한계를 극복하고 다음과 같은 이점을 제공한다:

1. 비즈니스 중심성: 도메인이 기술적 세부사항으로부터 독립
2. 테스트 용이성: 의존성 주입을 통한 격리된 단위 테스트
3. 유연성: 인터페이스 기반 설계로 구현체 교체 가능
4. 확장성: 마이크로서비스로의 자연스러운 전환 지원
5. 유지보수성: 명확한 관심사 분리와 단일 책임 원칙 준수

이러한 변화는 단순한 기술적 개선이 아닌, 소프트웨어 개발 패러다임의 근본적 전환을 의미한다.

Domain-Centric 구조적 구현

Clean Architecture 기반 구조

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

# 현대적 도메인 중심 구조
src/
├── domain/                    # Domain Layer (중심)
│   ├── entities/
│   │   ├── User.py           # 비즈니스 엔티티
│   │   └── Order.py
│   ├── value_objects/
│   │   └── Email.py          # 값 객체
│   ├── services/
│   │   └── OrderDomainService.py
│   └── repositories/          # 인터페이스만
│       └── IUserRepository.py
├── application/               # Application Layer
│   ├── use_cases/
│   │   ├── CreateUserUseCase.py
│   │   └── ProcessOrderUseCase.py
│   ├── dtos/
│   │   ├── CreateUserRequest.py
│   │   └── UserResponse.py
│   └── services/
│       └── ApplicationService.py
├── infrastructure/            # Infrastructure Layer
│   ├── repositories/          # 구현체
│   │   ├── SqlUserRepository.py
│   │   └── MongoOrderRepository.py
│   ├── external_services/
│   │   └── EmailService.py
│   └── persistence/
│       └── database.py
└── presentation/              # Presentation Layer
    ├── api/
    │   ├── UserController.py
    │   └── OrderController.py
    └── cli/
        └── UserCLI.py

Rich Domain Model 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

# Domain Layer - 비즈니스 중심 엔티티
from abc import ABC, abstractmethod
from typing import List
from .value_objects import Email, Money

class User:
    """Rich Domain Entity - 비즈니스 로직 포함"""
    
    def __init__(self, user_id: str, name: str, email: Email):
        self._id = user_id
        self._name = name
        self._email = email
        self._orders: List[Order] = []
        self._is_active = True
    
    def change_email(self, new_email: Email):
        """비즈니스 규칙: 이메일 변경"""
        if not self._is_active:
            raise ValueError("Inactive user cannot change email")
        
        self._email = new_email
        # 도메인 이벤트 발생
        self._domain_events.append(UserEmailChanged(self._id, new_email))
    
    def can_place_order(self, order_amount: Money) -> bool:
        """비즈니스 규칙: 주문 가능 여부"""
        return (self._is_active and 
                len(self._orders) < 10 and 
                order_amount.amount > 0)

# Value Object
class Email:
    """값 객체 - 불변성과 유효성 보장"""
    
    def __init__(self, value: str):
        if not self._is_valid(value):
            raise ValueError(f"Invalid email: {value}")
        self._value = value
    
    @property
    def value(self) -> str:
        return self._value
    
    def _is_valid(self, email: str) -> bool:
        return '@' in email and '.' in email.split('@')[1]
    
    def __eq__(self, other):
        return isinstance(other, Email) and self._value == other._value

의존성 주입 및 제어 역전

Interface 기반 설계

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# Repository Interface (Domain Layer)
from abc import ABC, abstractmethod
from typing import Optional, List

class IUserRepository(ABC):
    """Repository 인터페이스 - 도메인 계층에 위치"""
    
    @abstractmethod
    async def save(self, user: User) -> User:
        pass
    
    @abstractmethod
    async def find_by_id(self, user_id: str) -> Optional[User]:
        pass
    
    @abstractmethod
    async def find_by_email(self, email: Email) -> Optional[User]:
        pass

# Concrete Implementation (Infrastructure Layer)
class SqlUserRepository(IUserRepository):
    """구체적 구현 - 인프라스트럭처 계층"""
    
    def __init__(self, session: AsyncSession):
        self._session = session
    
    async def save(self, user: User) -> User:
        # ORM을 통한 영속성 처리
        user_entity = UserEntity.from_domain(user)
        self._session.add(user_entity)
        await self._session.commit()
        return user_entity.to_domain()

현대적 DI 프레임워크 활용

FastAPI 의존성 주입

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# dependencies.py - DI 설정
from fastapi import Depends
from sqlalchemy.ext.asyncio import AsyncSession

async def get_db_session() -> AsyncSession:
    async with SessionLocal() as session:
        yield session

def get_user_repository(
    session: AsyncSession = Depends(get_db_session)
) -> IUserRepository:
    return SqlUserRepository(session)

def get_create_user_use_case(
    user_repository: IUserRepository = Depends(get_user_repository)
) -> CreateUserUseCase:
    return CreateUserUseCase(user_repository)

# controller.py - DI 사용
from fastapi import APIRouter, Depends

router = APIRouter()

@router.post("/users")
async def create_user(
    request: CreateUserRequest,
    use_case: CreateUserUseCase = Depends(get_create_user_use_case)
):
    result = await use_case.execute(request)
    return UserResponse.from_domain(result)

NestJS 의존성 주입

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// user.service.ts
import { Injectable, Inject } from '@nestjs/common';

@Injectable()
export class UserService {
  constructor(
    @Inject('IUserRepository')
    private readonly userRepository: IUserRepository,
    private readonly eventBus: EventBus
  ) {}
  
  async createUser(request: CreateUserRequest): Promise<User> {
    const email = new Email(request.email);
    const user = new User(generateId(), request.name, email);
    
    const savedUser = await this.userRepository.save(user);
    
    // 도메인 이벤트 발행
    await this.eventBus.publishAll(user.domainEvents);
    
    return savedUser;
  }
}

// user.module.ts
@Module({
  providers: [
    UserService,
    {
      provide: 'IUserRepository',
      useClass: SqlUserRepository,
    },
  ],
  controllers: [UserController],
})
export class UserModule {}

Use Case 기반 애플리케이션 계층

Use Case 패턴 구현

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# Application Layer - Use Case
class CreateUserUseCase:
    """단일 책임을 가진 Use Case"""
    
    def __init__(self, 
                 user_repository: IUserRepository,
                 email_service: IEmailService,
                 event_publisher: IEventPublisher):
        self._user_repository = user_repository
        self._email_service = email_service
        self._event_publisher = event_publisher
    
    async def execute(self, request: CreateUserRequest) -> CreateUserResponse:
        # 1. 입력 검증
        if not request.name or not request.email:
            raise ValidationError("Name and email are required")
        
        # 2. 비즈니스 규칙 검증
        email = Email(request.email)
        existing_user = await self._user_repository.find_by_email(email)
        if existing_user:
            raise BusinessRuleViolation("User with this email already exists")
        
        # 3. 도메인 객체 생성
        user = User.create(request.name, email)
        
        # 4. 영속성 처리
        saved_user = await self._user_repository.save(user)
        
        # 5. 부수 효과 처리 (이벤트 발행)
        await self._event_publisher.publish(UserCreated(saved_user.id))
        
        # 6. 응답 생성
        return CreateUserResponse.from_domain(saved_user)

CQRS 패턴 적용

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

# Command와 Query 분리
class CreateUserCommand:
    def __init__(self, name: str, email: str):
        self.name = name
        self.email = email

class GetUserQuery:
    def __init__(self, user_id: str):
        self.user_id = user_id

# Command Handler
class CreateUserCommandHandler:
    def __init__(self, user_repository: IUserRepository):
        self._user_repository = user_repository
    
    async def handle(self, command: CreateUserCommand) -> str:
        user = User.create(command.name, Email(command.email))
        saved_user = await self._user_repository.save(user)
        return saved_user.id

# Query Handler
class GetUserQueryHandler:
    def __init__(self, user_read_model: IUserReadModel):
        self._user_read_model = user_read_model
    
    async def handle(self, query: GetUserQuery) -> UserDto:
        return await self._user_read_model.get_by_id(query.user_id)

도메인 이벤트 및 Event-Driven Architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57

# Domain Event
from dataclasses import dataclass
from datetime import datetime

@dataclass
class DomainEvent:
    occurred_on: datetime
    event_id: str

@dataclass
class UserCreated(DomainEvent):
    user_id: str
    name: str
    email: str

# Domain Entity with Events
class User:
    def __init__(self, user_id: str, name: str, email: Email):
        self._id = user_id
        self._name = name
        self._email = email
        self._domain_events: List[DomainEvent] = []
    
    @classmethod
    def create(cls, name: str, email: Email) -> 'User':
        user_id = generate_uuid()
        user = cls(user_id, name, email)
        
        # 도메인 이벤트 생성
        user._domain_events.append(
            UserCreated(
                occurred_on=datetime.utcnow(),
                event_id=generate_uuid(),
                user_id=user_id,
                name=name,
                email=email.value
            )
        )
        return user
    
    @property
    def domain_events(self) -> List[DomainEvent]:
        return self._domain_events.copy()
    
    def clear_domain_events(self):
        self._domain_events.clear()

# Event Handler
class UserCreatedEventHandler:
    def __init__(self, email_service: IEmailService):
        self._email_service = email_service
    
    async def handle(self, event: UserCreated):
        await self._email_service.send_welcome_email(
            event.email, 
            event.name
        )

주요 차이점 비교

실제 구현 예시 비교

전통적 방식 - 사용자 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 전통적 방식: 강한 결합, 절차적 처리
class UserController:
    def create_user(self, request):
        # 직접 DB 접근
        if UserRepository().find_by_email(request['email']):
            return {"error": "User exists"}
        
        user = User(request['name'], request['email'])
        user.save()  # Active Record 패턴
        
        # 직접 이메일 서비스 호출
        EmailService().send_welcome_email(user.email)
        
        return {"id": user.id}

현대적 방식 - 사용자 생성

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

# 현대적 방식: 느슨한 결합, 도메인 중심
@router.post("/users")
async def create_user(
    request: CreateUserRequest,
    use_case: CreateUserUseCase = Depends(get_create_user_use_case)
):
    try:
        result = await use_case.execute(request)
        return CreateUserResponse.from_domain(result)
    except ValidationError as e:
        raise HTTPException(status_code=400, detail=str(e))
    except BusinessRuleViolation as e:
        raise HTTPException(status_code=409, detail=str(e))

마이크로서비스와의 연계

현대적 접근법에서의 마이크로서비스 지원

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

# 각 서비스별 독립적인 도메인 계층
# User Service
src/user_service/
├── domain/
│   ├── User.py
│   └── IUserRepository.py
├── application/
│   └── CreateUserUseCase.py
└── infrastructure/
    └── SqlUserRepository.py

# Order Service  
src/order_service/
├── domain/
│   ├── Order.py
│   └── IOrderRepository.py
├── application/
│   └── ProcessOrderUseCase.py
└── infrastructure/
    └── MongoOrderRepository.py

# API Gateway에서 서비스 조합
class UserOrderController:
    def __init__(self, 
                 user_service_client: UserServiceClient,
                 order_service_client: OrderServiceClient):
        self._user_service = user_service_client
        self._order_service = order_service_client
    
    async def create_user_with_initial_order(self, request):
        # 분산 트랜잭션 또는 Saga 패턴 적용
        user = await self._user_service.create_user(request.user_data)
        order = await self._order_service.create_order(
            user.id, request.order_data
        )
        return {"user": user, "order": order}

장점

전통적 Layered Architecture 의 장점

현대적 Domain-Centric Layered Architecture 의 장점

전통적 vs. 현대적 접근법의 핵심 차이점

설계 철학의 차이

graph TD
    subgraph "Traditional Layered"
        A[Presentation Layer] --> B[Business Layer]
        B --> C[Data Access Layer]
        C --> D[Database Layer]
    end
    
    subgraph "Modern Domain-Centric"
        E[Infrastructure] --> F[Application]
        G[Infrastructure] --> F
        H[Infrastructure] --> F
        F --> I[Domain Core]
    end

장점별 상세 분석

관심사 분리 (Separation of Concerns)

전통적 접근법:

• 메커니즘: 기술적 책임에 따른 수평 분리
• 장점: 개발자가 특정 기술 영역에 집중 가능
• 한계: 비즈니스 로직이 여러 계층에 산재

현대적 접근법:

• 메커니즘: 비즈니스 개념 중심의 수직 분리
• 장점: 비즈니스 로직의 응집도 극대화
• 추가 가치: 도메인 전문가와의 의사소통 개선

테스트 용이성

전통적 접근법:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// 통합 테스트에 의존
@SpringBootTest
class UserServiceTest {
    @Autowired
    private UserService userService;
    
    @MockBean
    private UserRepository userRepository;
    
    @Test
    void shouldCreateUser() {
        // 데이터베이스 모킹 필요
    }
}

현대적 접근법:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// 순수 도메인 테스트
class UserTest {
    @Test
    void shouldCreateValidUser() {
        // 외부 의존성 없는 순수 테스트
        Email email = new Email("test@example.com");
        Name name = new Name("John Doe");
        
        User user = new User(email, name);
        
        assertThat(user.getEmail()).isEqualTo(email);
    }
}

확장성

전통적 접근법:

• 수직 확장: 전체 애플리케이션 단위 확장
• 제한: 특정 계층 병목 시 전체 확장 필요

현대적 접근법:

• 선택적 확장: 도메인별, 유스케이스별 독립 확장
• 마이크로서비스 준비: 바운디드 컨텍스트 기반 분할 가능

현대적 요구사항에 대한 대응

클라우드 네이티브 환경

전통적 방식의 한계:

• 모노리식 배포로 인한 확장성 제약
• 기술 스택 종속성으로 인한 클라우드 마이그레이션 어려움

현대적 방식의 장점:

• 컨테이너화 친화적 구조
• 서비스 메시와의 자연스러운 통합
• 클라우드 서비스 (서버리스, 관리형 서비스) 활용 용이

DevSecOps 와 보안

계층별 보안 강화:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# 현대적 보안 구현 예시
class SecurityLayerManager:
    def __init__(self):
        self.layer_policies = {
            "presentation": ["input_validation", "authentication"],
            "application": ["authorization", "rate_limiting"],
            "domain": ["business_rule_validation"],
            "infrastructure": ["data_encryption", "audit_logging"]
        }
    
    def apply_security(self, layer: str, operation: str):
        policies = self.layer_policies.get(layer, [])
        for policy in policies:
            self.enforce_policy(policy, operation)

단점과 문제점 그리고 해결방안

전통적인 Layered Architecture 단점 및 문제점

전통적인 구조는 직관적이고 프레임워크 친화적이지만, 비즈니스 로직이 분산되기 쉽고, 계층 간 결합도가 높아 변경이나 테스트에 취약하다. 의존성 주입, 인터페이스 분리, 단순화된 계층 구조가 주요 해결책이다.

현대적인 Layered Architecture–단점 및 문제점

현대적 구조는 도메인 주도 설계 (DDD) 에 기반하여 유연성과 유지보수성을 높이지만, 구조가 복잡하고 추상화가 과도할 수 있어 개발 생산성에 악영향을 줄 수 있다.
Vertical Slice, 단계적 도입, 테스트 템플릿화로 운영 효율성을 확보하는 것이 중요하다.

공통 해결 전략 요약

• 계층 수를 목적에 맞게 설계: 작은 프로젝트는 3-Layer, 도메인 중심은 4~5 Layer 구성.
• 인터페이스 기반 통신 (DIP): 추상화 도입으로 유연성과 교체 용이성 확보.
• 테스트 전략 세분화: Domain, Application, Infra 계층별로 독립 테스트 전략 구성.
• 코드 자동 분석 도구: 정적 분석, 의존성 시각화, 순환 참조 탐지 도구 활용.
• 계층 통합/간소화 시도: 반복적이고 의미 없는 계층 (Sinkhole) 은 통합하거나 생략.

도전 과제

1. 구조적 문제:
   Layered Architecture 는 명확한 경계를 기반으로 설계되지만, 계층 간 결합도 증가나 과도한 계층화로 인해 복잡성이 급증할 수 있다. 특히 DIP(Dependency Inversion Principle) 를 적용하지 않으면 구조가 경직되고 변경 비용이 높아진다.

2. 운영 및 테스트 측면:
   많은 계층은 테스트 환경 구성에 복잡성을 더하고, 계층별 책임이 분산되면 트랜잭션 경계가 모호해진다. 실시간 처리나 CI/CD 환경에서는 각 계층의 상태를 mocking 하거나 병렬로 테스트하기 어려운 문제가 생긴다.

3. 현대화 이슈:
   마이크로서비스나 클라우드 네이티브 아키텍처로 전환 시, 전통적인 계층 구조는 배포 단위, 확장성, 네트워크 처리에 대한 제약이 발생한다. 이벤트 중심 아키텍처, 서버리스, API Gateway 등을 활용한 리디자인이 필요하다.

4. 아키텍처 유연성 부족:
   비즈니스 로직이 도메인 외부 계층에 분산되면 핵심 도메인의 테스트 및 유지보수가 어려워지고, 로깅·인증 등 공통 관심사가 중복 처리되면 코드 일관성과 재사용성이 저하된다. 이는 미들웨어 또는 AOP 기반 공통 처리로 해결할 수 있다.

분류 기준에 따른 종류 및 유형

1. 계층 수 기준:
   시스템의 크기와 복잡도에 따라 2N 계층으로 나뉜다. 단순한 CRUD 위주의 시스템은 23 계층이 일반적이며, 대규모 시스템에서는 도메인, 서비스, 통합 계층 등을 추가한 4 계층 이상 구조가 요구된다.

2. 아키텍처 스타일:
   전통적인 Layered Architecture 는 구현이 쉽고 명확하나, 변화에 취약하다. Clean, Onion, Hexagonal 같은 현대적 아키텍처는 도메인 중심, DIP (의존성 역전 원칙) 적용, 테스트 용이성을 보장하며, 복잡성은 증가하지만 장기적인 유지보수에 강하다.

3. 계층 간 통신 방식:
   계층 간 호출 제한을 두는 방식 (Closed) 은 안정성과 테스트 용이성이 높고, Open 방식은 개발 속도와 성능 유리하지만 유지보수 리스크가 존재한다. 실무에서는 Closed 기반에 예외적으로 우회 호출을 허용하는 Hybrid 방식이 많이 사용된다.

4. 배포 구조:
   논리적 계층 분리는 동일 서버 내의 모듈화에 가깝고, 물리적 분리는 각 계층을 별도 인프라 (컨테이너, VM 등) 로 분리하여 클라우드, 보안, 확장성 측면에서 유리하다.

5. 의존성 방향:
   전통적인 방식은 하위 계층 (데이터) 에 의존하나, 현대적인 방식은 상위 계층 (도메인) 이 하위 구현에 의존하지 않도록 추상화하여 설계한다. 이는 유연성과 테스트성을 크게 향상시킨다.

6. 통신 방식:
   동기식 통신은 간단하고 직관적이지만, 응답 지연이나 장애 전파 위험이 있다. 반면 비동기식 통신은 복잡하지만 확장성과 복원력 확보에 강점을 가지며, 이벤트 기반 아키텍처와 연계된다.

7. 복잡도/적용 범위:
   간단한 Layered 구조는 개발이 빠르고 직관적이며 소규모 프로젝트에 적합하다. 복잡한 도메인 요구가 있는 경우엔 도메인 주도 아키텍처로 전환이 필요하며, 이때는 책임 분리와 의존성 통제가 중요하다.

3 계층 vs. N-Tier Architecture 비교

• 3 계층은 단순성과 빠른 개발을 추구할 때 적합.
• N 계층은 보안, 확장성, 역할 분리가 중요한 복잡한 시스템에 적합.

Layered Architecture vs. Clean Architecture

• Clean Architecture 는 Layered Architecture 를 인터페이스 기반으로 개선하여 결합도를 낮추고 핵심 도메인을 외부 변화로부터 보호하는 설계 철학이다.

• Clean vs Layered: Clean Architecture 는 Layered 구조의 추상화와 의존관리 강화 버전이며, 핵심 도메인의 독립성과 유연성을 강조

Strict Layered vs. Loose Layered

• 엄격 레이어드 아키텍처는 계층 간 의존성을 철저히 제한하여 모듈성과 예측 가능성이 매우 뛰어남. 테스트와 디버깅이 용이하며, 시스템이 커질수록 구조적 강점이 발휘됨. 단, 성능 병목과 유연성 부족이 단점.

• 유연 레이어드 아키텍처는 특정 상황에서 계층을 스킵하여 성능을 향상시킬 수 있는 장점이 있으나, 결합도 증가와 유지보수 복잡성의 리스크가 존재함. 실무에서는 대부분 이 모델을 사용하며, 정책적으로 우회 가능한 계층만 허용하는 절충 모델도 존재함.

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점