feat: 헥사고날 아키텍쳐

Author: gwanhyeon

spring/.DS_Store

@@ -0,0 +1,49 @@
+DDD 헥사고날을 쓰는이유
+1. 소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.
+객체지향의 본질의 핵심은 ?
+- 객체 그자체
+
+객체들을 어떻게 추려내고, 이 객체가 필요한지, 서로 상호작용하는지 어떻게 알 수 있을까요?
+- 도메인 주도 설계(Domain-Driven Design)
+
+간편 결제 서비스를 예를 들어보겠습니다.
+내가 간편결제 서비스는 포인트를 충전하기 위한 도메인, 충전된 포인트를 활용한 결제 도메인이 있을 수 있습니다.
+
+- 충전 도메인: 포인트, 고객, 충전 수단
+- 결제 도메인: 포인트, 고객, 결제 상품
+
+서로 다른 도메인이지만, 같은 객체(포인트, 고객)이 존재한다. 이는 같은 객체가 여러개 존재할 수 있다는 도메인 주도 설계의 특징중 하나입니다.
+같은 객체이지만, 그 객체가 속한 도메인의 문맥에 따라 각 객체의 역할과 책임이 바뀌는것입니다.
+
+즉,  서로 다른 도메인 역을 끼치기 위해서는 API를 이용해야하며 각각의 도메인은 서로 철저히 분리되고, 높은 응집력과 낮은 결합도로 변경과 확장에 용이한 구조를 얻게됩니다.
+
+그리고 DDD를 실제로 구현할 때에는 크게 3가지 Layer로 구분하는 것이 핵심입니다.
+1. Application Layer: 주로 도메인과 Repository를 바탕으로 실제 서비스(API)를 제공하는 계층
+2. Domain Model Layer: Entity를 활용해 도메인 로직(비즈니스 로직)이 수행되는 계층
+3. Infrastructure Layer: 외부와 통신(RDBMS, Redis, HttpClient, ...)을 담당하는 계층
+
+그럼 헥사고날 아키텍처는 무엇이고, 왜 쓰는걸까요?
+인프라 ← 서비스 ← 프레젠테이션의 방향으로 의존성이 설계된 MVC 아키텍쳐에서는 인프라의 변화가 곧 뷰의 변화로 이어지기 쉽습니다. 하지만 웹서비스에서의 핵심은 인프라가 아니라 실제 비즈니스 로직이 수행되는 서비스 계층, 더욱 정확하게는 개발팀의 의사소통 단위가 되는 도메인 객체들입니다.
+도메인 객체들은 근본적으로 서비스가 지니는 바운디드 컨텍스트 안에서 독립적인 로직을 가지고 있습니다. 영속성 계층, 혹은 메시지 큐와 같은 인프라는 결국 이러한 도메인의 상태를 저장하거나 전달하기 위해 존재할 뿐입니다. 즉, 도메인 객체들은 인프라에 의존하지 않아야 한다는 것입니다.
+그렇기 때문에 헥사고날 아키텍처는 의존의 방향이 레이어드 아키텍처와 다릅니다.
+클린 아키텍처와 마찬가지로 어디에도 의존하지 않는 도메인 객체들이 존재하고, 이들에 의존하는 서비스계층(또는 usecase 계층)이 존재합니다. 서비스계층에서 수행되는 비즈니스 로직들은 외부와 연결된 포트를 통해 시스템 외부로 전달되며 인프라는 포트에 의존합니다.
+한 마디로, 외부와의 통신을 인터페이스로 추상화하여 비즈니스 로직 안에 외부 코드나 로직의 주입을 막는다는 것이 헥사고날 아키텍처의 핵심입니다.
+
+Why DDD, Clean Architecture and Hexagonal ?
+그래서 DDD, Clean Architecture, Hexagonal Architecture에서 중요한건 뭘까요? 바로 명확한 관심사의 분리 입니다.
+외부와의 연결에 문제가 생기면 Adapter를 확인하면 될 것이고, 인터페이스의 정의를 변경하고자 한다면 Port를 확인하면 됩니다. 처리 중간에 Custom Metric 측정을 위해 Event Bridge에 이벤트를 보내거나 트레이스를 로그를 심고 싶다면 Service(usecase)를 확인하면 됩니다.
+마지막으로 비즈니스 로직이 제대로 동작하지 않는다면 Domain Model만 확인하면 되는 것이지요.
+이러한 구조는 결국 쉬운 테스트를 가능하게 해주기도 합니다. 본인의 역할을 수행하기 위해 필요한 Port만 모킹하여 테스트를 쉽게 수행할 수 있습니다.
+
+
+참조: https://dataportal.kr/74
+
+
+
+
+
+
+
+
+
+