PSD( Private-Self-Development )

헥사고날 아키텍처(Hexagonal Architecture) 본문

Backend/기타

헥사고날 아키텍처(Hexagonal Architecture)

chjysm 2024. 7. 15. 11:14

개발 아키택처의 방향성

  • 의존성 문제 해결
  • 비즈니스 로직 과 인프라 로직을 분리 하여, 비즈니스 로직에만 집중하고자 한다.
  • 이전에는 하나의 뭉텅이로 만들어 놓던 이전의 로직을
    각각의 역할 및 레이어로 분리하여, 유지 보수성 향상을 얻는다.

이러한 방향성을 실현하기 위한 것이
클린 아케텍처 이고, 이러한 클린 아케텍처를

좀더 구현성을 강화 한 것이 헥사고날 아키텍처 이다.

 

클린 아키텍처?

클린아키텍처

  • 추상화된 레이어를 통해 의존성을 역전 시켜 
    인프라를 수정해도 비즈니스 로직은 수정하지 않아도 되도록 구현하는 아키텍처
  • 유즈케이스 추상화 레이어를 통해 전체적인 흐름을 제어
  • 의존성은 외부 -> 내부 로만 존재
  • Entities (엔터프라이즈 비즈니스) <- Use Cases(어플리케이션 비즈니스) <- Interface Adapters <- Frameworks and Drivers 로 의존성 역전을 시킨다.
  1. Entities
    1. 어플리케이션의 비즈니스 규칙을 캡슐화한 객체
  2. Use Cases
    1. 어플리케이션의 비즈니스 로직이 구현되는 곳 엔티티로 부터 비즈니스 규칙을 받아 사용자의 요구사항을 처리한다.
  3. Interface Adapters
    1. 데이터 변환 담당한다.
    2. 사용자나 외부 시스템으로부터 오는 요청을 유즈 케이스와 엔티티가 이해할 수 있는 형식으로 변환하고
      유즈 케이스와 엔티티의 응답을 반환할 때에도 그 역할을 담당한다.
  4. Frameworks and Drivers
    1. UI, DB, 외부 인터페이스 들의 구체적인 구현이 이루어 진다. 

단점

  • 무엇이 클린한 상태인지 생각이 다 다르다.
  • 그림만 보면 레이어드 아키텍처? 와 다를게 없어 보이는데 실제 내용은 달라서 헷갈린다.

 

 

헥사고날 아키텍처?

헥사고날 아키텍처

  • 포트 앤 어답터 아키텍처 라고도 알려져 있다.
  • 어플리케이션 코어 부 와 인터페이스(포트) 를 통해 주변의 다양한 어플리케이션 서비스(어댑터) 로 부터 분리하는 것
  • 장점
    • 명확한 관심사의 분리
      • 외부 연결 문제 => 어댑터
      • 인터페이스 문제 => 포트
      • 처리 중간 이번트 처리 나 트레이스 로그를 심고 싶다면 => 서비스
      • 비즈니스 로직에 문제 => 도메인 모델
  • 어플리케이션 코어( 도메인 계층 <- 어플리케이션 서비스 ) <- 포트 <- 어댑터  로 의존성 역전을 시킨다.
  1. 도메인 계층
    1. 모든 엔티티에 대한 변경은 여기서만 실행
    2. 어떠한 의존성도 없어야 하는 것이 원칙이다.
      1. 단, 예외적으로 레포지토리의 경우에는 포트를 이용하여 어댑터를 주입받아서 이용가능
    3. 구성
      1. 엔티티 : 도메인의 핵심 개념을 모델리링
      2. VO : 속성들의 집합 이를 통해 도메인의 특정 측면을 표현한다
      3. 도메인 서비스 : 특정 엔티티나 값 객체에 속하지 않는 도메인 영역의 로직
      4. Aggregates : 연관된 객체 집합을 하나의 단위로 관리
      5. Aggregates Root : 각 집합체 내에서 엔티티의 진입점 역할을 하는 엔티티
  2. 어플리케이션 서비스
    1. 어댑터를 주입 받아서 
      도메인 계층과 인터페이스 계층 사이의 조정 역할을 수행한다.
    2. 사용자의 명령을 처리하고 조회를 수행한다.
      유즈케이스 담당
  3. Ports
    1. 입력 포트(  Api 인터페이스 )
      1. 외부 요청을 애플리케이션 코어로 전달
    2. 출력 포트
      1. 애플리케이션 코어가 인프라스트럭처 레이어 에 상호작용 
  4. 어댑터
    1. 포트를 통해 인프라와 실제로 연결하는 부분만 담당 
    2. 구성
      1. 입력(인바운드) 어댑터
        1. http 웹 요청, 메시징 큐 메시지 등 외부에서 오는 요청을 입력 포트가 정의한 방식으로 변환 
          EX) 스프링 웹 컨트롤러
      2. 출력(아웃바운드) 어댑터
        1. 출력 포트를 통해 어플리케이션 고어가 필요로 하는 외부 서비스 를 실행 
          EX) Jpa  리포지토리

 

 


참고

https://velog.io/@roo333/%EC%A7%80%EC%86%8D-%EA%B0%80%EB%8A%A5%ED%95%9C-%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4-%EC%84%A4%EA%B3%84-%ED%8C%A8%ED%84%B4-Hexagonal-Architecture

 

지속 가능한 소프트웨어 설계 패턴: DDD + Hexagonal Architecture

Intro 이번에 글로벌 프로젝트를 하면서 안정적이고 튼튼한 소프트웨어를 만들고 싶어 설계에 대해 공부를 많이 하게되었습니다. 그 중에 제가 알게된 육각형 설계(Hexagonal Architecture)에 대해 설명

velog.io

 

https://www.youtube.com/watch?v=MKfSLrwLex8

'Backend > 기타' 카테고리의 다른 글

키클락( keycloak )  (2) 2024.12.17
Maven 다중 프로젝트 설정  (0) 2024.12.17
도커( Doker )  (0) 2024.04.29
최소 지식 원칙( 데메테르의 법칙 )  (0) 2023.05.23
Nginx 란?  (0) 2023.01.19