- 기존 계층형 아키텍처는 비즈니스 로직이 컨트롤러 및 영속성 계층으로 유출되어 테스트 및 유지보수가 어렵고, 기술 스택 변경 시 큰 영향을 미칩니다. 🚫
- 프레임워크에 비즈니스 로직이 강하게 결합되어 프레임워크 버전 업그레이드 시 기능적 회귀가 발생하거나, 다른 기술 스택으로의 이식이 불가능해지는 문제가 있습니다. 🔗
- 계층 간의 강한 결합은 한 계층의 문제(예: 컴파일 오류)가 전체 시스템으로 전파되는 연쇄 반응을 일으켜 시스템을 취약하게 만듭니다. 💥
- 헥사고날 아키텍처(포트 및 어댑터)는 이러한 문제들을 해결하기 위한 대안으로, 소프트웨어 복잡성과 기술 부채 관리에 효과적입니다. 🛡️
- 핵심 원칙은 비즈니스 로직(도메인)을 최우선으로 '성역화'하여 한 곳에 모으고, 이를 통해 기능 테스트 작성을 용이하게 하는 것입니다. ✨
- 도메인은 어떤 기술 계층에도 의존하지 않으며, 오히려 외부 기술 계층(영속성, 웹 서비스 등)이 도메인에 의존하는 '의존성 역전' 원칙을 따릅니다. 🔄
- 도메인 내부에는 프레임워크를 사용하지 않고, 순수 비즈니스 로직만 포함하여 '본질적 복잡성'을 관리하며, 외부 기술 계층은 '필수적 복잡성'을 담당합니다. 🧠
- 도메인과 외부 세계의 상호작용은 '포트'라고 불리는 인터페이스를 통해 이루어지며, 이는 API(외부 -> 도메인)와 SPI(도메인 -> 외부)로 나뉩니다. 🔌
- API는 컨트롤러와 같은 외부 요소가 도메인 기능을 호출하는 계약이며, SPI는 도메인이 외부 데이터나 서비스를 사용하는 계약입니다. 🤝
- 이러한 포트들은 오직 도메인 객체에만 의존하여 기술적 오염을 방지하고, 외부 기술 스택(예: REST, SQL) 변경 시 도메인 코드 수정 없이 어댑터만 교체할 수 있게 합니다. 🧱
- 헥사고날 아키텍처 개발은 항상 도메인(비즈니스 로직)부터 시작하며, 인수 테스트 주도 개발(ATDD)을 통해 헥사고날의 형태를 잡아나갑니다. 🚀
- 이를 통해 애플리케이션의 지속 가능성을 높이고, 기술 변화에 유연하게 대응할 수 있는 견고한 구조를 구축할 수 있습니다. 🌱
Recommanded Videos
