토이프로젝트를 진행하면서 헥사고날 아키텍처(Hexagonal Architecture) 로 설계하고 구현하기로 했다. 진행을 하면서 헥사고날 아키텍처를 정리 할 필요를 느꼈다. 예전에 관련 책이나 강의를 본 적도 있고, 그 때에는 잘 이해 했다고 생각 했다.
하지만 실제 코드로 구현하고 의존성에 대한 방향에 대한 고민과 의문, 그리고 적절한 패키징 구조를 생각하면서 끊임없이 코드 변경의 과정을 거쳤다.
결국 완벽하지는 않고, 정답은 아니지만 나의 방식대로 헥사고날 아키텍처를 구현한 내용을 정리 해 보려고 한다.

레이어드 아키텍처와의 비교

비교적 익숙한 레이어드 아키텍처(Layered Architecture) 는 계층별로 책임을 분리하여 시스템을 설계한다. 그러나 시간이 지남에 따라 레이어드 아키텍처는 변경에 취약하고, 테스트하기 어려운 구조로 변질되거나, 그렇게 설계될 가능성이 있다.
이러한 문제를 해결하기 위해 헥사고날 아키텍처(Hexagonal Architecture) 를 대안으로 많은 선배 개발자들이 이 설계 방식을 제안하고 있다. 레이어드 아키텍처의 구조와 비교하며, 어떤 점에서 헥사고날 아키텍처가 이점을 갖는지 알아보며 정리하고자 한다.

1. 레이어드 아키텍처란?

레이어드 아키텍처는 소프트웨어 시스템을 계층으로 나누어 설계하는 전통적인 방식이다. 일반적으로 표현 계층(Presentation Layer), 비지니스 계층(Business Logic Layer), 데이터 접근 계층(Data Access Layer)로 구성되는 3계층의 형태가 일반적인 레이어드 아키텍처의 구조이다.

• 표현 계층: 사용자 인터페이스(UI)와 상호작용을 담당
• 비즈니스 로직(Service) 계층: 애플리케이션의 핵심 로직을 처리하는 부분, 비즈니스 규칙과 관련된 연산이나 데이터 처리 로직을 포함
• 데이터 접근 계층(Infrastructure): 데이터베이스와 상호작용을 담당

레이어드 아키텍처의 구조

challenge
│  ChallengeApplication.java
│  
├─controller
│      ChallengeController.java
│
├─service
│      ChallengeService.java
│
├─repository
│      ChallengeRepository.java

간단한 패키지와 코드 구현을 나타내면 위와 같다. challenge라는 애플리케이션을 구현하기로 한다. 위 구조에서 service와 repository 레이어에서 따로 인터페이스로 구현하고, 따로 구현체를 만드는 경우가 많다.(여기서는 가장 단순한 구조를 예시로 한다.)
레이어드 아키텍처의 개념과 대응하면 다음과 같다.

패키징 구조와 개념과의 대응

controller : 표현 계층 (Presentation Layer)

• 사용자로부터의 입력 을 받아들이고, 응답 을 반환한다
• 뷰(View) 와 모델(Model) 사이의 상호작용을 관리

service : 비지니스 계층 (Business Logic Layer)

• 비즈니스 로직을 처리하고, 도메인 객체를 활용한다. (여러 도메인을 엮어 비지니스 로직을 수행 해야 할 때)
• 트랜잭션 관리
• 데이터 접근 계층과 상호작용하여 데이터의 저장 및 조회 등을 수행

repository : 데이터 접근 계층 (Data Access Layer)

• 데이터베이스나 파일 시스템 등 외부 시스템과의 데이터의 직접 접근을 담당
• CRUD(생성, 조회, 갱신, 삭제) 작업을 수행

레이어드 아키텍처의 특징과 장점

특징

레이어드 아키텍처에서 의존성은 일반적으로 상위 계층에서 하위 계층으로 흐른다.

Controller → Service → Repository

• 위와 같은 구조에서 상위 계층(Controller)이 하위 계층(Service) 에 의존하고, 다시 Service 계층은 Repository 계층에 의존한다.

의존성의 방향은 내부에서 외부로 흐른다. 비즈니스 로직 계층이 외부의 UI나 DB에 의존하기 때문이다.

내부와 외부의 정의
나는 의존성의 흐름과 방향의 설명을 봤을 때 제대로 이해가 가지 않았다. 자세히 찾아보니 이 설명에서 말하고 있는 내부와 외부의 정의가 기존의 생각과는 달랐기 때문이다. 아래의 정의를 기준으로 설명을 보면 이해할 수 있을 것이다.

• 내부(Inside): 시스템의 핵심 비즈니스 로직이나 도메인 로직을 뜻한다. 이 부분은 애플리케이션의 본질적인 규칙과 행동을 담당하는 중심부이다. 즉, 비즈니스 규칙을 결정하는 도메인 로직이 있는 곳이 내부이다.
• 외부(Outside): 데이터베이스, 사용자 인터페이스(UI), 외부 시스템(API), 프레임워크 등의 비즈니스 로직을 지원하는 기술적인 요소를 의미한다. 이는 주로 시스템의 입출력, 외부와의 상호작용을 담당한다.

장점

• 이해하기 쉽고 명료한 구조
  각 계층이 명확한 책임을 가지고 있기 때문에 시스템의 구조를 쉽게 이해할 수 있다.
• 유지보수성 향상
  계층별로 명확하게 분리된 책임 덕분에, 특정 계층에서 문제가 발생하면 해당 계층만 수정할 수 있다. 이로 인해 유지보수가 용이하다.
  새로운 기능을 추가할 때도 기존 계층을 수정하지 않고 새로운 계층만 추가하거나 변경하는 방식으로 확장할 수 있다.
• 테스트 용이성
  각 계층이 독립적으로 모듈화되어 있기 때문에, 계층별로 단위 테스트를 수행하기 쉽다.
• 단순한 의존성 관리
  레이어드 아키텍처에서는 상위 계층이 하위 계층에 의존하는 일관된 구조를 가지므로 의존성 관리가 상대적으로 단순하다. 각 계층이 아래 계층에만 의존하면 되기 때문에 계층 간의 복잡한 의존 관계를 관리할 필요가 적다.

소규모나 중간 규모의 프로젝트에서 적합하며, 표준화된 방식으로 빠르게 시스템을 구축하고 확장할 수 있다는 장점이 있다.

2. 레이어드 아키텍처의 문제점

레이어드 아키텍처는 초기에는 이해하기 쉽고 간단하게 시작할 수 있다. 하지만 시스템이 커지면서 다음과 같은 문제가 발생할 수 있다. 장점으로 나타난 부분이 오염되어갈 가능성이 나타난다.

• 의존성 역전 위반: 상위 계층이 하위 계층의 구현체에 의존하게 되어 변경에 취약해 진다.
• 유지보수의 어려움: 비즈니스 로직이 여러 계층에 분산되어 유지보수가 어려워진다.
• 테스트 어려움: 외부 시스템과 강하게 결합되어 단위 테스트가 어려워진다.

위 내용은 레이어드 아키텍처의 문제를 검색 해 봤을 때 나오는 단점이다. 하지만 위 문제는 레이어드 아키텍처 자체의 문제라고 보기에는 어려운데, 각각의 구현 원칙과 방법을 잘 선택하면 전혀 발생시키지 않을 수도 있는 문제이다. 간단하게는 다음과 같은 방법으로 해결이 가능하다. 위에서 제시하는 단점은 개념적 문제점이라고 생각하자.

• 의존성 역전 위반 : 의존성 주입을 사용하여 구현체를 주입하는 방식으로, 의존성을 역전시켜서 구현체에 직접 의존하는 않도록 설계 및 구현.
  (하지만 의존성 흐름이 내부에서 외부로만 흐르는 문제는 여전히 해결 할 수 없다. 비즈니스 로직이 데이터 접근 계층의 세부 사항이나 외부 기술에 영향을 받게 될 가능성이 높다.)
• 유지보수의 어려움 : 비지니스 레이어에서만 비지니스 로직을 담당하도록 한다.
  (이 부분은 실제로는 의도적으로 생각하고 있지 않으면 해결하기 어려운 부분이라고 생각한다. 데이터베이스에서의 결과를 처리하거나, 쿼리 자체에 비지니스 로직이 포함되는 경우가 빈번히 발생 할 수 있기 때문)
• 테스트 어려움 : 직접 구현체를 사용하지 않고, 의존성을 주입을 통해 구현체를 주입 받는 식으로 설계하고 목(Mock) 구현체 등을 사용하여 외부 의존성을 제거하면 단위(소형) 테스트로의 전환이 가능하다. (의존성 역전을 제대로 지키면 자연스럽게 따라오는 부가효과이다. 단 의존성 흐름이 여전히 내부에서 외부로 흐르기 때문에 외부의 영향을 예상한 테스트를 작성 할 수 없다. 또 상위 계층이 하위 계층에 의존하는 구조를 가지고 있기 때문에, 테스트 과정에서 필요없는 하위 계층의 의존성이 필요하거나 완전 독립된 테스트를 하기에는 어렵다)

헥사고날 아키텍처는 이러한 문제점을 해결하기 위해 의존성 역전 원칙을 적용하고, 도메인 모델을 중심으로 설계하고자 한다.

3. 헥사고날 아키텍처란?

헥사고날 아키텍처는 포트와 어댑터 패턴(Ports and Adapters Pattern) 으로도 불리며, 도메인 로직을 중심으로 외부와의 의존성을 분리하는 설계 방식이다. 이 내부의 구조 영역을 크게 다음의 3개의 영역으로 나누면 다음과 같다.

주요 구조 영역

도메인 헥사곤 (Domain Hexagon)

• 핵심 비즈니스 로직과 도메인 모델이 위치하는 영역
• 외부 시스템이나 기술 스택에 의존하지 않는 순수한 코드로 작성된다
• 비즈니스 규칙과 상태 관리를 담당하며, 애플리케이션의 가장 핵심적인 부분으로 가장 내부영역이다

주요 구성 요소

• 도메인(Domain) 객체: 상태와 행동을 포함하는 객체로 핵심 비지니스로직을 가지고 있다
• 값 객체(Value Object): 불변 객체로, 하나의 값을 나타내며 식별자가 없음

애플리케이션 헥사곤 (Application Hexagon)

• 포트(Port) 를 정의하여 도메인 헥사곤과 외부 세계를 연결
• 유스케이스(Use Case)를 구현하여 비즈니스 작업의 흐름을 관리하는 영역
• 트랜잭션 관리, 권한 검사, 로깅 등의 작업을 수행

주요 구성 요소

• 입력 포트(Input Port): 외부에서 들어오는 요청을 처리하는 인터페이스
• 출력 포트(Output Port): 외부 시스템과의 통신을 위한 인터페이스
• 유스케이스 구현체(Use Case Implementation): 입력 포트를 구현하여 비즈니스 로직을 실행

프레임워크 헥사곤 (Framework Hexagon)

• 어댑터(Adapter) 를 정의하고 외부 시스템과의 통신을 담당
• 웹 프레임워크, 데이터베이스 접근, 메시징 시스템 등 기술적인 직접 구현이 위치
• 외부로부터의 입력과 출력을 처리하며, 구체적인 기술 스택에 의존한다

주요 구성 요소

• 입력 어댑터(Inbound Adapter): 외부 요청을 받아 애플리케이션 헥사곤의 입력 포트를 호출
• 출력 어댑터(Outbound Adapter): 애플리케이션 헥사곤의 출력 포트를 구현하여 외부 시스템과 상호작용 함

헥사고날 아키텍처의 구조

challenge
│  ChallengeApplication.java
│  
├─application
│  ├─dto
│  │      ChallengeInputDTO.java
│  │      ChallengeOutputDTO.java
│  │
│  ├─port
│  │  ├─inbound
│  │  │      CreateChallengeUseCase.java
│  │  │
│  │  └─outbound
│  │          ChallengeRepository.java
│  │
│  └─service
│          CreateChallengeService.java
│
├─domain
│  ├─model
│  │      Challenge.java
│  │
│  └─vo
│          AdditionalInfo.java
│          ...
│
└─framework
    └─adapter
        ├─inbound
        │  └─web
        │          ChallengeController.java
        │          CreateRequest.java
        │          CreateResponse.java
        │		   ...
        │
        └─outbound
            └─jpa
            	└─entity
                		   ChallengeJPAEntity
                           ...
             ChallengeJpaAdapter.java
             ChallengeJpaRepository.java

헥사고날(Hexagonal)은 육각형을 뜻하는데, 아키텍처의 구조를 그림으로 간단히 나타내면 위와 같다.
패키징이나 네이밍에 대해서는 딱히 정답은 없다. 나는 개념적인 부분을 코드에도 적용시키고자, 상위 패키지 이름을 domain, application, framework로 정의 했고, 각각의 헥사곤 영역을 나타내게 표현했다.

헥사고날 아키텍처의 구조와 패키징 구조를 의도적으로 매칭 시켰다. 내부와 외부의 경계를 코드만으로 이해하고, 의존성의 방향과 흐름을 이해하기 쉽도록 의도했다.

패키징 구조와 개념과의 대응

domain 패키지: 도메인 헥사곤 (Domain Hexagon)

• 비즈니스 도메인 모델을 표현하는 엔티티(Entity)와 값 객체(Value Object) 를 정의
• 도메인 모델은 비즈니스 규칙과 상태를 관리
• 여러 도메인이 협력하는 경우 별도의 도메인 서비스로 묶어서 규칙을 정의 할 수도 있음
• 애플리케이션의 독립적인 부분으로, 외부 시스템이나 프레임워크에 의존하지 않는다

코드 예시

DDD를 기반으로 풍부한 도메인 코드를 구현하면, 자연스럽게 가장 코드의 양이 많은 영역이 된다. 도메인 코드의 객체 생성 규칙, 검증, 비지니스 로직 등은 생략 한 예시이다. 또 도메인은 값 객체를 사용하여 도메인을 더 의미 있고 직관적으로 표현 할 수 있다.

public class Challenge {

    private final Long challengeId;
    private final Long userId;
    private final String nickName;
    private final Period period;
    
    // ...
}

application 패키지: 애플리케이션 헥사곤 (Application Hexagon)

• 포트(Port) 를 정의하여 도메인 헥사곤과 외부를 연결.
  • 입력 포트 (InputPort / Inbound) : 외부의 입력을 처리하기 위한 인터페이스. 코드 내에서는 UseCase라는 이름으로 명명했다.
  • 출력 포트 (OutputPort / Outbound) : 외부 출력을 위한 인터페이스. DB의 저장이나 통신 등을 외부 시스템으로 본다. 코드 내에서는 Repository로 명명했다. 여기에서 Repository는 그 어떤 외부 저장소에 대한 정보를 알지 못한다.
  • 서비스 (service) : 애플리케이션 서비스를 뜻한다. 주로 트랜잭션을 관리하며 입력 포트(UseCase) 의 구현체이다.
  • DTO (Data Transfer Object) : 애플리케이션 헥사곤에서 데이터를 전달하기 위한 객체이다. 외부 입력이나 외부 출력의 경우 실제 도메인이 가진 정보 그대로 모두 전달 하거나 받을 필요가 없고, 필요한 데이터만 관리하기 위한 목적으로 사용한다.

코드 예시

입력 포트

public interface CreateChallengeUseCase {
    ChallengeOutputDTO createChallenge(ChallengeInputDTO challengeInputDTO);
}

InputPort에 해당한다. 외부의 입력을 받고 (이 입력은 DTO를 통해서 받는다) 이것을 처리하기 위한 인터페이스다.

출력 포트

public interface ChallengeRepository {
    Challenge save(Challenge challenge);
}

OutputPort에 해당한다. 외부 출력을 위한 인터페이스로, 여기서는 도메인을 저장하는 행위 자체만을 정의했다.

(애플리케이션) service

@Service
@Transactional
@RequiredArgsConstructor
public class CreateChallengeService implements CreateChallengeUseCase {

    private final ChallengeRepository challengeRepository;

    @Override
    public ChallengeOutputDTO createChallenge(ChallengeInputDTO challengeInputDTO) {
        Challenge challenge = Challenge.create(null, challengeInputDTO.getUserId(), challengeInputDTO.getNickName(),
                new Period(challengeInputDTO.getStartDate(), challengeInputDTO.getEndDate()),
                GoalContent.create(challengeInputDTO.getMainContent(), challengeInputDTO.getAdditionalContent(), GoalType.valueOf(challengeInputDTO.getGoalType())),
                challengeInputDTO.getAttachedImagePaths(), challengeInputDTO.getChallengeCertificateImagePath());
        return ChallengeOutputDTO.from(challengeRepository.save(challenge));
    }
}

service에 해당하며, InputPort의 구체적인 구현체이다. 하지만 여기서도 구체적인 외부의 저장소를 알지 못한다. 전달 받은 외부의 DTO 값을 객체로 만들고, 이 생성된 객체를 통해 외부로 저장을 요청한다. 이 결과값으로 받은 값 또한 다시 출력을 위한 DTO로 변환된 값을 받도록 했다.

framework 패키지: 프레임워크 헥사곤 (Framework Hexagon)

• 어댑터(Adapter) 를 정의하며, 애플리케이션 헥사곤과 외부를 연결.
  • 입력 어댑터 (inbound) : 외부의 입력을 처리하며, 구체적인 기술 스택에 의존한다. 코드 내에서는 추가적인 패키징으로 web하위에 controller를 구현했다. HTTP 요청을 통한 구체적인 웹 요청을 처리한다.
  • 출력 어댑터 (outbound) : 외부의 출력을 처리하며, 주로 구체적인 DB나 외부 통신의 구현을 한다. 코드 내에서는 JpaAdapter를 통해 JPA를 구현하기로 했다.

코드 예시

입력 어댑터

@RestController
@RequiredArgsConstructor
public class ChallengeController {

    private final CreateChallengeUseCase createChallengeUseCase;

    @PostMapping("/challenges")
    public ResponseEntity<CreateResponse> createChallenge(@RequestBody @Valid CreateRequest request) {
        return ResponseEntity.ok(CreateResponse.toDTO(createChallengeUseCase.createChallenge(request.toDTO()));
    }
}

프레임워크 헥사곤은 실제 기술의 의존하며, 구현하는 영역이다. 이 코드의 입력 어댑터는 Rest방식의 WebController를 사용한 것이 된다. 애플리케이션 헥사곤에서 구현한 CreateChallengeUseCase를 통해 필요한 데이터를 전달하여, 사용자의 요청을 처리한다.

나의 경우는 특별히 여기서 별도의 Request와 Response 객체를 따로 만들었다. API 요청과 응답을 나타내는 DTO이다. 여기서 Request에서 사용자 입력 값을 전달받고, 값 검증과 같은 로직을 담당하며, Response는 사용자에게 API에 맞는 출력을 위해 사용한다.
외부의 입력과 출력만을 위한 단일책임과 역할분리를 위해서 만들었다. 이 결과로 애플리케이션 헥사곤에 데이터를 전달하기 위한 DTO로 변환하는 번거로운 작업과 비용이 발생했다. 하지만 유지보수와 책임 분할이라는 이점을 생각하면 나쁘지 않은 선택이라고 생각한다.

출력 어댑터

@Repository
@RequiredArgsConstructor
public class ChallengeJpaAdapter implements ChallengeRepository {

    private final ChallengeJpaRepository challengeJPARepository;

    @Override
    public Challenge save(Challenge challenge) {
        return challengeJPARepository.save(ChallengeJPAEntity.fromDomain(challenge)).toDomain();
    }
}

public interface ChallengeJpaRepository extends JpaRepository<ChallengeJPAEntity, Long> {}

출력 어댑터로, 구체적인 외부의 저장소를 로직을 구현했다. JPA의 기술을 통해 저장하며, 이 단계에서도 외부의 의존성 주입을 통해서 SprigDataJPA를 사용할 수 있게 처리했다.
추가로 나의 경우는 별도의 JPAEntity 코드를 정의 했다. 순수 도메인과 거의 1:1로 대응하지만, JPA의 영속성을 위한 JPAEntity 객체 코드로 명확한 역할을 구분하기 위해서 별도로 분리하였다.

헥사고날 아키텍처의 특징과 장단점

특징

헥사고날 아키텍처에서의 의존성은 항상 외부에서 내부로 향하도록 설계되어야 한다. 가장 내부는 도메인 헥사곤 영역이다.

• 프레임워크 헥사곤은 애플리케이션 헥사곤의 포트에 의존한다.
• 애플리케이션 헥사곤은 도메인 헥사곤에 의존한다.
• 도메인 헥사곤은 어떤 외부에도 의존하지 않는다.

헥사고날 아키텍처에서 핵심은 비즈니스 로직과 외부 시스템의 의존성을 분리하는 것에 있기 때문에 레이어드 아키텍처 처럼 수직관계인 상위, 하위 개념으로 설명하지 않고 외부와 내부로 표현하는게 적절하다고 한다.

의존성의 방향은 외부에서 내부로 흐른다.
데이터베이스, 외부 API, UI 같은 외부 의존성은 내부 비즈니스 로직에 의존하지만, 비즈니스 로직은 외부의 세부 사항에 의존하지 않는다. 따라서 내부의 핵심 비즈니스 로직은 외부 시스템(DB, UI, 외부 API 등)에 대해 몰라도 된다. 내부 로직은 기술적인 세부 사항에 의존하지 않고, 외부 시스템이 변경되더라도 비즈니스 로직은 영향을 받지 않는다. 즉 도메인 헥사곤 영역의 코드만으로도 완벽하게 돌아가는 프로그램인 것이다.

Web서비스를 가정한 상호작용의 흐름

1. 클라이언트가 HTTP 요청을 보낸다.
2. 입력 어댑터(ChallengeController)가 요청을 받아 입력 포트(CreateChallengeUseCase)를 호출한다.
3. 유스케이스 구현체인 CreateChallengeService가 비즈니스 로직의 흐름을 제어하고, 모든 비즈니스 규칙은 도메인(Challenge)에서 처리된다.
   필요에 따라 출력 포트(ChallengeRepository)를 호출한다.
4. 출력 어댑터(ChallengeJpaAdapter)가 출력 포트(ChallengeRepository)를 구현하여 데이터베이스에 접근하고, DB에 직접적으로 데이터를 저장하거나, 조회, 삭제 등을 수행한다.
5. 결과는 역순으로 반환되어 클라이언트에게 응답된다.

장점

• 유지보수성 향상: 핵심 비즈니스 로직은 외부 시스템과 분리되어 있어, 외부 시스템의 변경이 발생해도 비즈니스 로직은 그대로 유지될 수 있다. 이를 통해 변경 사항에 대한 영향 범위가 줄어들고, 코드의 일관성을 유지할 수 있다
• 테스트 용이성 증가: 외부 의존성이 분리되어 단위 테스트가 쉬워지며 완전 독립성을 가진 테스트를 만들 수 있다 특히, 외부 시스템에 대한 모킹(Mocking) 을 통해 도메인 로직을 독립적으로 테스트할 수 있으며, 이를 통해 테스트 속도와 신뢰성이 높아진다
• 확장성 확보: 어댑터를 통해 외부 시스템을 쉽게 교체할 수 있고, 새로운 기능을 추가할 때도 기존 도메인 로직에 영향을 주지 않으므로 확장성이 뛰어나다. 만약 새로운 외부 시스템을 만드는 경우에도 내부의 도메인에는 아무런 영향을 주지 않기 때문에 자연스럽게 OCP 원칙을 지키며 유연한 개발이 가능하다
• 의존성 관리 용이: 의존성 방향이 명확하여 코드와 데이터의 흐름을 이해하기 쉽다

단점

• 복잡성 증가: 초기 설계 시 개념을 이해하고 적용하는 데 시간이 필요하다. 계층별로 인터페이스와 어댑터를 분리하다 보니, 규모가 작은 애플리케이션에서는 오버엔지니어링(Over-engineering)이 발생할 수 있다
• 개발 속도 저하: 레이어드 아키텍처에 비해 초기 개발 속도가 느릴 수 있다. 계층별로 인터페이스와 구현체를 분리하고, DTO 변환 작업 등이 추가된다
• 과도한 추상화 위험: 필요 이상으로 추상화를 진행하면 오히려 코드 복잡도가 증가하고, 이해하기 어려운 구조가 된다. 추상화가 과도해질 경우, 인터페이스와 구현체의 분리가 너무 세분화되어 전체 코드의 복잡도가 증가할 수 있으며, 각 모듈 간의 연결이 불명확해질 수 있다

헥사고날 아키텍처를 직접 구현 해 보며

설계 원칙은 명확하며 쉽다. 의존성과 의존성의 흐름이 항상 외부에서 내부로 가도록 설계하면 된다. 이것은 의존성 역전의 원칙을 지키며, 인터페이스를 통해 구현할 수 있다.
하지만 막상 실제 코드로 구현 해보니 개인적으로는 쉽지는 않았다.
추가로 인터페이스 분리 원칙을 지키면서 이것이 포트와 어댑터 패턴으로 나타나면서 여러 코드들이 나타나며 이 구조를 따라가는게 처음에는 쉽지 않았다.
찾아보는 자료마다 패키징 구조와 함께 명칭이 조금씩은 달랐기에, 어느 것을 표준으로 해야하는 지에 대한 선택의 고민이 있었다. 하지만 단순히 모양을 따라하고 싶은게 아니라 직접적인 목적과 의미를 이해해보고 싶은 마음에 혼자서 여러 시행 착오를 거치며 나름의 독자적인 형태를 완성했다. 나의 결과는 정답은 아니라는 것을 알고, 아마 실제로 개발을 한다고 해도 일부 원칙과 타협해야 하는 지점이나, 오용하는 부분이 생길 것이다. 그럼에도 우선 기본 형태 자체는 이상적인 형태는 만들어 봤으니 만족을 하고 있다.

토이프로젝트를 진행하며, 이 헥사고날 아키텍처 자체는 과도한 오버엔지니어링인 것을 사전에 인지하면서까지 구현 해 본 결과 가장 크게 이점으로 느꼈던 점은 테스트 용이성이였다.
사실 이전까지만해도 모킹(Mocking)을 통한 테스트에 부정적이였다. 실제 값이 아니기 때문에 100% 신뢰할 수 없는 테스트 결과라는 생각과 함께, 계층별로 테스트가 성공한다고 해도, 통합 테스트로 테스트가 이어지는 경우 성공하지 못하는 가능성 등의 요인을 부정적으로 생각했다.
헥사고날 아키텍처로 구현하면서 완전히 독립된 테스트가 작성하기 때문에 모킹을 통한 테스트에 대해 신뢰성을 더 믿을 수 있게 되었다. 또 명확한 계층 구조의 이해와 테스트를 수행 할 수 있어서 자연스럽게 TDD/BDD 를 쉽게 적용 할 수 있는 점이 큰 이점으로 다가왔다.

코드 구현에 대한 복잡성과 개발 속도의 저하 문제가 있지만, 복잡한 비즈니스 로직을 다루는 시스템에서는 충분히 고려해 볼 만한 가치가 있다고 생각한다. 결과적으로는 변경이 많이 예상되는 시스템에서는 더욱 유연한 변경과 안정적인 시스템 검증과 개발이 가능 할 것으로 보기 때문이다.

다만 레이어드 아키텍처에서도 도메인 계층을 분리하고(4계층 레이어드 아키텍처) DDD 관점에서 설계하며 의존성 역전 원칙을 활용하면, 충분히 테스트가 용이하며 유지보수성과 확장성을 갖춘 시스템을 만들 수 있다고 생각한다. 모든 일은 트레이드 오프 (Trade-Off)가 있는 법이며 은탄환은 없기 때문에 (No Silver Bullet) 실무에서는 프로젝트의 규모, 변경가능성, 팀원의 개발 역량 등을 고려해서 적절한 아키텍처를 선택하면 좋을 것 같다.