헥사고날 아키텍처 전환

[limehee]

Describe

헥사고날 아키텍처로의 전환 이유

1. 직접적인 계층 간 통신

• 기존 계층형 아키텍처에서는 Controller -> Service -> Repository로 향하는 의존성이 강제됩니다. 이는 상위 계층에서 하위 계층에 대한 직접적인 의존성을 초래하여 결합도를 높이고, 테스트 코드 작성이 어렵습니다. 이러한 의존성은 변경 사항이 다른 계층으로 전파되는 문제를 일으킬 수 있습니다.

2. 패키지 구조에서의 의존성 관리 어려움

• 계층형 아키텍처에서는 패키지 간의 의존성을 명확하게 관리하는 것이 어렵습니다. 헥사고날 아키텍처는 의존성 규칙을 명확히 하여 코드 작성 시 의식적으로 계층 및 도메인 간의 의존성과 결합도를 고려하도록 유도합니다. 이는 코드를 명확하고 쉽게 이해할 수 있게 도와줍니다.

3. 의존성과 결합도 문제

• 도메인 간 또는 계층 간의 얽힌 의존성은 기능 수정 시 다른 기능에 예기치 않은 영향을 줄 수 있습니다. 테스트 커버리지를 높게 유지하는 것은 현실적으로 매우 어렵고 비용이 많이 들며, 얽혀있는 의존성은 인수인계 시 이해하기 어려운 경우가 많습니다.

4. 협업의 어려움

• 계층형 아키텍처는 Controller, Service, Repository로 분리되어 작업합니다. 동일한 도메인이나 연관된 기능에 대해 여러 명이 동시에 작업할 경우, 변경 사항 간 충돌이 발생하기 쉽습니다. 이러한 충돌은 해결 후에도 새로운 버그를 유발할 수 있으며, 테스트 코드가 있어도 완벽히 해결되지 않을 수 있습니다.

5. 변경의 어려움과 코드 중복

• 서비스나 비즈니스 로직이 중복되거나 여러 곳에서 재사용되는 경우가 많습니다. 이는 코드의 유연성을 떨어뜨리고, 변경 시 중복된 코드를 일일이 수정해야 하는 어려움을 초래할 수 있습니다.

6. 도메인 지식의 분산

• 비즈니스 로직이 여러 계층에 걸쳐 분산될 수 있어, 도메인 지식을 코드베이스 전반에 걸쳐 관리해야 하는 어려움이 있습니다.

Tasks

• 외래키 제거 #388

• 엔티티 간 직접적인 참조를 제거하고 ID를 통한 간접 참조로 전환합니다. 도메인 간 결합도를 낮추기 위한 작업입니다.

• 계층 간 인터페이스 추가 및 유스케이스 분리 #392

• 도메인 간 결합도를 낮추고 인터페이스를 도입하여 계층 간 통신을 추상화합니다.

• 비즈니스 로직과 애플리케이션 로직을 분리하여 유스케이스 별로 관리합니다.

• 헥사고날 아키텍처에서는 유스케이스가 핵심적인 요소로, 이들 간의 명확한 분리가 필요합니다.

• 도메인 객체를 POJO로 전환 #401

• 도메인 객체를 순수한 POJO로 만들고 JPA 엔티티와 분리하여 관리합니다. 이는 도메인 객체와 영속성 로직을 분리하여 각자의 책임을 명확히 하기 위함입니다.

• 아키텍처 규칙 문서화

• 헥사고날 아키텍처의 규칙과 지침을 문서화하여, 팀 내 개발자들이 동일한 방식으로 코드를 작성하고 유지보수할 수 있도록 합니다.

ETC

• 헥사고날 아키텍처 전환 이후 코드 리뷰 및 시스템 통합 테스트를 철저히 진행할 예정입니다.
• 기존 시스템과의 호환성을 유지하기 위해 단계적 전환을 고려하고 있습니다.