hexagonal architecture 사실과 오해

1. Hexagonal architecture 사실과 오해(1)

1. Architecture

• 시스템의 기본적인 구조를 정의

• 시스템의 중요한 품질 속성에 큰 영향을 미침

• 설계 결정의 기반이 되는 핵심적인 개념

• 기본 구성요소, 상호관계, 제약 조건 그리고 원칙 등을 포함

1.1 계층형 아키텍쳐(Layered Architecture)

• 서브 시스템을 계층으로 구조화 하는 아키텍쳐 스타일

• 계층은 사용 관계로 연결

• 사용 관계는 '일반적으로 단방향이어여 한다'라는 제약을 갖음

  • 상위 계층이 하위 계층의 서비스를 사용하는 하향식 흐름을 가짐

• 각 계층이 하위 계층의 내부 작동 방식을 알지 못하고, 제한된 인터페이스만 사용해야 한다. (계층 격리)

  • 어떤 레이어의 변경이 다른 레이어의 컴포넌트에게 가능한 영향을 주어선 안된다.

1.2 3계층 아키텍쳐

⬇️ 요청
1. UI (= Presentation)
2. Domain (= Business Logic, Transaction Script)
3. Data (= Persistence, Infra)
⬇️ 응답

1.3 4계층 아키텍쳐

⬇️ 요청
1. UI (= Presentation)
2. Application Service
3. Domain (= Business Logic, Transaction Script)
4. Data (= Persistence, Infra)
⬇️ 응답

---

2. 헥사고날 아키텍쳐 알아보기

• 대칭형(Symmetric) 아키텍쳐

• 위 아래, 좌 우가 아닌 애플리케이션의 내부와 외부 세계 라는 구조를 가짐

  • 그래서 육각형으로 이를 설명

• 헥사곤의 내부

  • 쉽게 변하지 않는 중요 도메인 로직을 담는 코어 애플리케이션
    • 도메인 로직을 가진 트랜잭션 스크립트
    • 애플리리케이션 서비스와 도메인 모델 패턴을 따라 만든 도메인

• 헥사곤의 외부

  • 헥사곤과 상호작용 하는 모든 것(액터)
    • ex) 사용자, 브라우자, CLI 명령, 기계, 다른 System, 운영 환경, DB, 메시징 시스템, 메일 시스템 등

• 헥사고날 아키텍쳐의 특징과 혜택

  • 테스팅!. 운영 System에 연결되지 않고, 애플리케이션 테스트

    • 애플리케이션과 상호작용하는 액터가 바뀌어도, 다시 빌드 하지 않고 테스트

  • UI 디테일이나 기술정보가 도메인 로직 안으로 노출되지 않도록 보호. (반대도 마찬가지)

  • 컴포넌트를 각각 개발, 연결하는 방식으로 큰 시스템을 분리

  • 시간이 지나면서 외부 연결을 다른 것으로 변경 할 수 있다.

  • 기술 요소를 제거했기 때문에 도메인 설계에 집중 할 수 있다.

---

1. Hexagonal architecture 사실과 오해(2)

1. 헥사곤을 부르는 여러가지 이름

• 헥사곤

• 애플리케이션

• 앱

• 코어 시스템

• SuD(System under Development)

• SuT(System under Test)

2. 액터와 애플리케이션의 상호작용은 어떻게 하나?

• Port

  • 애플리케이션이 외부 세계와 의도를 가지고 상호작용 하는 아이디어를 캡쳐하는 것
  • 단순히 데이터를 주고 받는 것이 아닌, 명확한 목적과 방향을 가지고 외부와 연결.
  • 애플리케이션이 정의한 인터페이스로 만들어짐

• 인터페이스

  • Lolipop : Provided Interface (기능 제공 인터페이스)

  • Socket : Required Interface (기능 요구 인터페이스)

    

• 어댑터

  • 애플리케이션의 포트를 직접 연결할 수 없다면 인터페이스의 변환을 위해 어댑터를 사용

  • 브라우저를 통해서 애플리케이션의 회원가입 포트의 기능 제공 인터페이스를 사용하려면?

    • 회원 가입 기능 제공 인터페이스를 사용해 웹 컨트롤러 어댑터를 만들기

  • 애플리케이션이 가진 회원 정보 저장 포트의 기능 요구 인터페이스로 DB와 직접 연결 할 수 없다면?

    • 기능 요구 인터페이스를 구현한 레포지토리 어댑터를 만들기

포트와 어댑터 아키텍쳐

• 헥사고날 아키텍쳐의 특징을 담은 새로운 이름
• 여전히 포트와 어댑터 아키텍쳐보다 헥사고날 아키텍쳐란 이름이 많이 사용.

3. 헥사고날 아키텍쳐의 비대칭성

• 애플리케이션이 제공하는 기능을 사용하는 액터와 이를 위한 어댑터

  • primary actor, primary adapter

  • driving actor, driving adapter

• 애플리케이션이 동작하는데 필요한 기능을 제공하는 액터와 이를 위한 어댑터

  • secondary actor, secondary adapter
  • driven actor, driven adapter

4. 오해

• 애플리케이션 내부에 도메인 계층을 만들어여 한다. -> X

  • 헥사고날 아키텍쳐는 애플리케이션 내부 구현에 대한 원칙이나 요구사항이 없다.

    • 스파케티 코드로 만들어도 된다
    • 트랜잭션 스크립트, 도메인 모델 패턴과 애플리케이션 서비스 등도 가능하다.
    • 도메인 계층을 포함하는 아키텍쳐는 클린 아키텍처다.

  • 헥사고날 아키텍처는 클린 아키텍처, 어니언 아키텍처가 아니다

• 헥사고날 아키텍처 패키지 구조를 따라야 한다. -> X

  • 헥사고날 아키텍처가 요구하는 패키지 구조는 없다.
  • 애플리케이션과 어댑터 패키지를 분리하는 것은 바람직
  • 포트를 구분된 패키지에 두는 것을 권장.

• 포트는 UseCase라는 접미사를 사용한다 -> X

  • 포트의 의도를 담는 이름을 사용하면 된다.
  • For+ing 스타일의 권장 네이밍이 있지만, 필수는 아니다.

• 애플리케이션에는 도메인 모델만 넣고, JPA 엔터티 등은 어댑터에 둬야한다 -> X

  • 애플리케이션 코드와 포트 인터페이스가 외부 기술에 의존하지 않으면 된다.

5. 사실

• 애플리케이션은 모든 외부와 상호작용을 위해서 Provided Interface와 Required interface를 정의한다

• 애플리케이션과 상호작용하는 액터는 런타임에 구성돼야 한다

• 애플리케이션은 액터에 대한 코드 의존성을 가지면 안됌

• 액터는 정의된 포트를 통해서만 연결돼야 한다.

• 포트의 인터페이스는 기술 의존성을 가지지 않는다.