![[만들면서 배우는 헥사고날 아키텍처 설계와 구현] 1-1 왜 헥사고날 아키텍처인가?](/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fattachment%253A68d504b4-11d3-43c7-a84f-a0022bcea985%253A%25E1%2584%2592%25E1%2585%25A6%25E1%2586%25A8%25E1%2584%2589%25E1%2585%25A1%25E1%2584%2580%25E1%2585%25A9%25E1%2584%2582%25E1%2585%25A1%25E1%2586%25AF.jpeg%3Ftable%3Dblock%26id%3D25fa12d0-8f8e-809e-96fa-ce6aa9f47b2f%26cache%3Dv2&w=1920&q=75)
![[만들면서 배우는 헥사고날 아키텍처 설계와 구현] 1-1 왜 헥사고날 아키텍처인가?](/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fattachment%253Aa9a7f440-8e90-4576-8e02-a70518fd1979%253A%25E1%2584%2592%25E1%2585%25A6%25E1%2586%25A8%25E1%2584%2589%25E1%2585%25A1%25E1%2584%2580%25E1%2585%25A9%25E1%2584%2582%25E1%2585%25A1%25E1%2586%25AF.jpeg%3Ftable%3Dblock%26id%3D25fa12d0-8f8e-809e-96fa-ce6aa9f47b2f%26cache%3Dv2&w=1920&q=75)
왜 헥사고날 아키텍처인가?
소프트웨어 아키텍처 검토
소프트웨어 아키텍처는 건축물과 다르지만, 둘 다 '무언가를 올바르게 만든다' 라는 이상을 공유한다.
이러한 이상은 단지 동작하는 소프트웨어가 아닌, 쉽게 유지보수할 수 있고 잘 구성된 소프트웨어를 만들려고 하는 경우,
소프트웨어를 만들기 위해 도입한 세부사항에 대한 주의와 관심 때문에 고결한 정의로 볼 수 있다.
보이지 않는 것들
고객이 볼 수 없는 것 또한 어느 정도 중요하며, 이를 비기능적 요구사항이라고 한다.
보안, 유지보수성, 운영 가능성, 그리고 다른 기능과 관련된 것들이다.
비기능적 요구사항에 적절한 주의를 기울이지 않으면 그것들이 소프트웨어의 목적을 손상시킬 수 있다.
이러한 타협은 미묘하고 점진적으로 발생할 수 있으며, 기술 부채를 포함한 여러 문제의 원인이 된다.
올바르게 만드는 것에 관한 것이 되려면 문제 영역에 대한 깊은 이해가 필수이다.
도메인 주도 설계(DDD: domain driven design) 같은 기법은 문제에 접근하는 데 도움이 될 수 있다.
기술 부채
기술 부채(technical debt)라는 용어는 소프트웨어 코드 내에 존재하는 불필요한 복잡성이 얼마나 존재하는지를 설명한다.
이런 불필요한 복잡성을 크러프트(cruft)라고 한다.
크러프트: 코드에 남아있는 중복되고 방해되는 모든 것을 의미.
개발자가 동작하는 소프트웨어를 개발한다. 이후 새로운 개발자가 투입돼, 새로운 비즈니스 요구 사항을 충족시키기 위해 적절한 방법으로 코드를 조립하지만,
기존 코드에 이 개발자가 명확하게 이해하지 못하는 것들이 있다.
이 개발자는 기존과 약간 다른 방법으로 소프트웨어 요소들을 추가한다.
그렇게 사이클이 반복된다.
악순환
반복되는 사이클속에 프로젝트는 점점 더 관리하기가 어려워진다.
지속가능성. 그것이 소프트웨어의 가치를 알 수 있는 잣대같다.
아키텍처는 모두를 위한 것이 아니다.
커다란 진흙 덩어리(big ball of mud)에서 지적했듯이, 회사에서 이윤을 주도하는 소프트웨어가 완전히 커다란 진흙 덩어리인 경우가 있다.
bbom: 인지할 수 있는 아키텍처가 없는 소프트웨어 시스템을 말한다. 다수의 요소가 강하게 결합되어 변경이나 유지보수가 어려운 엉망인 상태의 코드를 의미하기도 한다.
주인의식이 없는 프로젝트에는 높은 품질의 코드를 만들도록 독려하기 어렵다.
모놀리식 시스템과 분산 시스템
뒤엉켜 있어 유지보수가 어려운 모놀리식 시스템과 유지보수 가능하고 응집력 있는 모놀리식 시스템을 구부하는 희미한 선만 있었다.
이러한 선을 넘는 것은 위험 신호이며, 시스템이 너무 많은 책임을 축적하고 있고 유지하기에는 과도하게 복잡해서
조금만 변경해도 전체 시스템이 망가질 수 있는 심각한 위험성을 내포하게 된다.
충부난 책임이 축적되는 시점을 안다면 전체 소프트웨어 아키텍처에 대해 다시 생각하고,
때로는 자율적으로 큰 모놀리식 시스템을 런타임 환경에서 격리되는 소프트웨어 구성 요소인 더 작고 관리하기 쉬운
소프트웨어 컴포넌트로 분해할 수 있다. 이 방법은 서비스 지향 아키텍처(SOA: Service Oriented Architecture)와 함께 채택되었으며,
SOA의 진화라고 할 수 있는 MSA에도 채택되었다.
헥사고날 아키텍처는 모놀리식 시스템과 분산 시스템 모두에 적용할 수 있다.
헥사고날 방식은 프런트엔드와 데이터베이스 없이 테스트할 수 있는, 변경에 더 강한 모놀리식 시스템을 개발하는 데 도움이 될 수 있다.
분산 시스템에서는 다양하고 많은 기술을 다룰 수 있다.
포트와 어댑터의 특성으로 인해 계속되는 기술의 변화를 소프트웨어가 처리할 수 있기 때문에 분산 시스템 환경에서 빛을 발한다.
의사결정
올바른 방식으로 제품을 만들기 위한 모든 시간과 노력이 가치가 없을 수도 있다.
왜냐하면 가능한 한 빨리 동작하는 소프트웨어를 전달해야하기 때문.
결국 우선순위가 문제다.
그러나 나중에 문제를 고칠 수 있다는 함정에 빠지지 않도록 조심해야 한다.
소프트웨어 코드가 잘 구성되고 유지보수 가능한 정도는 소프트웨어의 내부 품질에 해당한다.
사용자 관점에서 소프트웨어가 얼마나 가치 있고 좋은지에 대한 가치 인식은 외부 품질에 해당한다.
대부분의 소프트웨어 시스템에서는 시간이 지남에 따라 새로운 기능을 추가하는 것이 더 어려워진다.
이것은 비용이 증가함에 따라 새로운 기능이 표시되는 시간이 더 오래 걸린다는 것을 의미한다.
그렇다면 우리는 어떻게 올바른 결정을 내릴 수 있을까?
는 속임수 질문일 가능성이 크다. 충분한 정보를 얻을 때까지 기다리는 것이며, 그러면 결정에 더 확신을 가질 수 있다.
이 방법은 자연스럽게 정보 부족 및 발생하는 변경 사항을 수용할 필요성과 관련된 우리의 관심사를 반영하는 소프트웨어 아키텍처로 이어진다.
헥사고날 아키텍처 이해
"여러분의 애플리케이션을 UI나 데이터베이스 없이 동작하도록 만드십시오. 그러면 애플리케이션에 대해
자동화된 회귀 테스트를 실행할 수 있고, 데이터베이스를 사용할 수 없을 때도 동작합니다.
그리고 어떤 사용자의 개입 없이도 애플리케이션을 함께 연결할 수 있습니다."
헥사고날 아키텍처의 주된 아이디어 중 하나는 비즈니스 코드를 기술 코드로부터 분리하는 것이다.
그뿐만 아니라 기술 측면이 비즈니스 측면에 의존하는지도 확인해 비즈니스 측면이
비즈니스 목표를 달성하는 데 사용되는 기술에 대한 우려 없이도 발전할 수 있게 해야 한다.
또한 관련된 비즈니스 코드에 피해를 주지 않고도 기술 코드를 변경할 수 있어야 한다.
이러한 목표를 달성하려면 비즈니스 코드가 어디에 존재해야 하는지, 기술 문제로부터 격리되고 보호돼야 하는 위치를 결정해야 한다.
이것은 우리의 첫 번째 헥사곤, 즉 도메인 헥사곤(Domain hexagon)을 생성하게 될 것이다.
도메인 헥사곤에서는 소프트웨어가 해결하기를 원하는 핵심 문제를 설명하는 요소들을 결합한다.
도메인 헥사곤에서 활용되는 주된 요소는 엔티티(entity)와 값 객체(value object)다.
entity는 식별자(identity)를 할당할 수 있는 것을 의미하며, 값 객체는 엔티티들을 합성하기 위해 사용하는 불변 컴포넌트다.
애플리케이션 헥사곤(Application hexagon)을 통해 도메인 헥사곤에서 나오는 비즈니스 규칙을 사용, 처리하고 조정한다.
애플리케이션 헥사곤은 비즈니스 측면과 기술 측면 사이에 있으며, 양쪽과 상호작용하는 중개자 역할을 한다.
포트와 유스케이스를 사용해 이러한 기능을 수행한다.
프레임워크 헥사곤(Framework hexagon)은 외부 인터페이스를 제공한다.
REST, gRPC 엔드포인트를 정의하거나, 외부 소스에서 무언가를 소비하기 위해 DB, message broker, 다른 시스템에서 데이터 가져오기 등.
어댑터를 통해 기술 결정을 구체화한다.