🥜 [Conference] Hexagonal Achitecture 에 대해서 (GDSC Kprintf)

(GDSC Kprintf)

해당자로는 GDSC 컨퍼런스에 참여하여 들은 강의 내용 소감을 바탕으로

작성 된 포스트 입니다.

개요

한창 프로젝트를 만들다보면 난관에 봉착하게 되는데

첫 번째로 돌아는가는데 쓰레기장 코드인경우

두 번째로 돌아가진 않는데 구조를 이쁘게 짠 경우이다.

둘 다 정말 거지같은 경우이지만 해당 상황을 어떻게 이겨나가야 하는지

개선방안과 관점 변화를 받은 내용이라 포스팅 해볼까 한다.

소프트웨어 아키텍쳐란?

여러 가지 소프트웨어 구성요소와 그 구성요소가 가진 특성 중 외부에 드러나는 특성

그리고 구성 요소 간의 관계를 표현하는 시스템 구조나 구조체

행위와 구조 중 뭐가 더 높은 가치인가

프로젝트를 구현하려 하다보면

일단 돌아가긴 하는데 오류가 많은 프로젝트와

동작은 하지 않았지만 설계를 정말 잘해둔 프로젝트를 접하게 될 것이다.

이러한 상황에서 어떻게 프로젝트를 이어가야할지 알아가보려는 시점에서

행위(동작) 과 구조(설계) 중 무엇을 더 중점적으로 설계 해야 하는지 생각을 해보게 되었다.

1. 일단 동작함
2. 유지 보수하기 힘듬
3. 테스트도 없음
4. 사실상 폐기

1. 당장 동작은 안하지만
2. 수정을 금방 할 수 있음
3. 개선 가능
4. 지속 가능 프로젝트

따라서 구조가 좋다 > 유지보수하기 쉽다 > 비용이 적게 들어감 > 프로젝트가 장기간 지속

Q. 정말 구조 가 소프트웨어가 제공하는 가치인가?

흔하게 접하게 되는 코드는 “정리가 안된 방”과 같다

(책상이 책상 정리가 안되어 있어 역할 조차 할 수 없는 상황)

(구조가 좋지 않기 떄문에 책상 위에 무언가를 추가로 둘 수 없음)

정리하자면 '행위'는 '구조'에 의지하게 된다

---

아키텍쳐의 목적

아키텍쳐의 주된 목적은 시스템의 생명주기를 지원하는 것 인데,

좋은 아키텍쳐는 시스템을 쉽게 이해, 개발, 유지보수 를 하게 해주면서 배포까지 도와준다.

따라서

아키텍처의 궁극적인 목표는 시스템의 생명과 비용을 줄이는 것이다.

---

When ?

아키텍쳐가 무엇일까?

지켜야 하는 제약조건들의 집합

---

클린 아키텍쳐란?

중요도, 관심사에 따라 계층을 나누게 되는데 이에 따라서

관심사를 분리하여 의존성이 내부의 고수준을 향하도록 설계해야 한다.

WEB -> Controllers -> UseCases -> Entities (이러한 방향으로 흘러간다…)

이러한 클린 아키텍쳐에는 크게 3가지가 있는데

1. Hexagonal Architecture
2. Boundary Control Entity
3. Data Context and Interaction

이 중 Hexagonal Architecture 가 이번에 다뤄 볼 주제이다.

---

Hexagonal Architecture

(Hexagonal Architecture)

Hexagonal Architecture 를 위한 규칙

1. DIP 를 통해 고수준 바라보기
2. Entity 를 분리해 Usecase를 Infra Layer 로 부터 독립
3. port 를 통한 경계 분리
4. Adapter 를 통한 진입점 생성

위의 4가지 규칙을 따르면 된다.

하지만 기존의 아키텍쳐의 문제점을 알아야 개선방안을 파악하기 쉽다.

게층형 아키텍쳐의 불편했던 점

데이터베이스 중심적인 설계를 주도함

도메인 코드는 엔티티의 상태를 변경하는 일을 중심으로 하기 때문에

Entity 를 도메인 계층으로 올린다

순환 참조가 발생해버림

DIP 를 적용하여 의존성의 방향을 뒤집음

Business Layer 의 Entity 와 Infra layer 의 Entity 분리

Entity 를 분리하여 usecase 를 Infra layer 로 부터 독립시키기

Port 를 통한 경계 분리

Incoming Port 와 Outgoing Port 를 통해 경계 분리

해당작업을 통해야 Adapter 또한 의미가 살아나기 시작함

해당 방법을 통하면 UseCase 가 명확해진다.

Use Case : 내가 만들고자 하는 시스템 (서비스)

강의를 들은 후 느낀 점

JPA Entity 와 Domain Entity

를 분리했을 때

1. Domain Entity 를 다룰 때 연관관계, 매핑 즉시로딩 지연로딩등 고민이 줄어듬
2. 자연스럽게 핵심 비즈니스 로직에 집중

안했을 때

1. 무조건 분리하지 않아도 됨 JPA Entity 자체정도는 문제 x -> 변경 여지가 거의 x
2. 오히려 여러 객체를 관리하고 변환하는 과정이 없어 비용적인 측면에서 이득

Incomming Port 가 필수인가?

incomming port 가 없어도 의존성의 방향은 고수준을 향하여 흐르고 있기 때문에 없어도 되는 것 아닐까?

하지만 어지간하면 만들자

접근 제한자

public > protect > default > private

default 접근 제한자가 왜 중요한가

단일 진입점을 만들기 위해서, 외부에서 접근하지 못하게 함

deafult 를 사용함으로서 직접적으로 Usecase 에 접근할 수 없도록 함

마치며

따라서

기능을 지지하는 구조가 제일 중요하다.

기능이 있는 건 당연해야 하고 구조가 이를 뒷받침 해주어야 한다.

따라서 구조에 의존하여 더 안정적이고 유지보수하기 좋은 애플리케이션을 만들자는

다짐을 하게 되었다.