SW/마이크로서비스

마이크로서비스 : 헥사고널 아키텍처 : 개념, 개요, 정의

얇은생각 2020. 5. 5. 19:30
반응형

Layer 간의 의존성

UI 클라이언트가 Presentation Layer를 이용하고, Presentation 층이 Business Logic 층을 호출하고, Business Logic 층이 Data Access 층을 호출하고, Data Access 층이 저장소를 접근하게 됩니다.

어플리케이션에서 모든 영역이 중요하겠지만 가장 핵심적인 부분은 아무래도 어플리케이션이 제공하는 주요 서비스의 업무 로직을 담고 있는 Business Logic 층입니다. Presentation 층과 Data Access 층은 기술 트렌드에 따라 다양하게 교체 변화 가능하나, 핵심 비즈니스 기능은 한 번 정의되면 잘 변경되지 않습니다.

따라서 시스템의 확장성과 유연성을 높이기 위해 Layered Architecture는 이러한 기술 영역과 Business Logic 층을 구분하여 서로 영향을 받지 않도록 많은 노력을 기울여왔습니다. 일방향에 의존하기 때문에 의존하는 층에 영향을 받을 수밖에 없습니다.

예를 들어 제일 하위에 존재하는 Data Access 층의 데이터베이스를 교체한다면 Business Logic 층에 영향 없이 변경하기는 힘듭니다. 이러한 단점을 해결하는 방안이 Hexagonal Architecture입니다.

 

 

헥사고널

WEB Application은 크게 Business Logic을 처리하는 영역과 Business Logic의 결과를 처리하는 영역으로 나눌 수 있습니다. 여기서 로직의 결과를 처리하는 영역은 결과를 사용자에게 보여주는 영역과 저장하는 부분으로 다시 나눠질 수 있습니다.

어플리케이션에서는 Business Logic을 처리하는 영역이 제일 중요하며, Business Logic의 결과를 어떻게 다룰지 구현하는 기술, 즉 브라우저에 표현하는 기술이나 DB에 저장하는 기술은 비즈니스 로직에 영향을 미치지 않게 하는 것이 가장 좋은 설계라고 할 수 있습니다.

 

 

헥사고널 아키텍처의 추구 방향

사용자 인터페이스나 저장소가 변경이 되어도 구현 처리를 하는 층이 그 차이점을 흡수해서 Business Logic 층이 영향이 없게 해야 합니다.

Hexagonal Architecture는 다양한 이질적 클라이언트가 동등한 지위에서 시스템과 상호작용을 하는 대칭성을 만들어줍니다 . 보통 Port Adaptor Pattern이라고도 합니다.

 

마이크로서비스 : 헥사고널 아키텍처 : 개념, 개요, 정의

 

이것이 Hexagonal Architecture의 개념도입니다. Hexagonal Architecture는 외부와 내부, 두 주요 영역을 가지고 있습니다. 외부 영역은 이질적인 클라이언트가 Input을 보낼 수 있도록 해주며, 영속 데이터를 가져 오거나 내부 영역의 Output을 데이터베이스에 저장하는 역할과 또는 다른 위치로 전송하는 메시지 메커니즘을 제공합니다.

외부에서 연계되는 타임마다 이에 특화된 어댑터가 존재하고, 외부 영역은 API를 통해 내부 영역과 이어집니다. 새로운 클라이언트가 필요할 경우, 단순히 내부 영역의 API가 클라이언트의 입력을 이해하도록 변환해주는 어댑터만 추가해 주면 됩니다.

즉, 내부 영역의 변경 없이 브라우저를 위한 어댑터, 모바일을 위한 어댑터를 만들면 됩니다. 이렇게 하면 내부 영역은 변화가 없고 시스템이 사용하는 그래픽, 영속성, 메시징과 같은 출력 메커니즘이 다양해지고 쉽게 대체될 수 있는 것입니다. API를 통해 외부 영역과 연계되는 내부 영역은 어플리케이션과 도메인 영역으로 구성되고, 기술에 독립된 순수한 Biz 개념과 로직을 표현하게 됩니다.

 

 

Dependnecy Inversion Principle : 의존관계의 역전 원칙

의존관계 역전의 원칙은 기왕 의존하려면 잘 변경되지 않는 부분에 의존해야 한다는 원칙입니다. 즉, 안정된 방향으로 의존하여 다른 패키지가 영향 받을 때 영향을 덜 받도록 하는 것입니다. 이를 Layered Architecture에 적용하면 다른 Layer에 가장 큰 영향을 줄 것 같은 위치에 있는 Layer의 의존 방향을 바꿈으로써 적용할 수 있습니다.

기존의 Architecture는 각 Layer 간 인터페이스 호출을 통해 의존성을 낮추고 있지만, 각 Layer는 아래 Layer의 인터페이스 변경에 영향을 받을 수밖에 없습니다. 그렇지만 위 Layer가 아래 Layer보다 안정적인 Layer라면 아래 Layer의 인터페이스를 위의 Layer에 위치시키고, 아래의 Layer 구현체는 위 Layer의 정의된 인터페이스에 의존하여 구현할 수 있습니다.

즉, 의존관계를 역전하여 위 Layer가 아래 Layer에 의존하지 않고 아래 Layer가 위 Layer에 의존할 수 있도록 하는 것입니다. 한 회사에서 쇼핑몰을 만들었는데 오라클 데이터베이스를 사용해서 데이터 처리를 수행합니다. 그런데 회사가 성장함에 따라 데이터베이스의 용량이 늘어나고, 데이터베이스 라이선스 비용이 많이 들어가게 되었습니다.

그래서 CIO는 데이터베이스 유지비용이 저렴한 오픈소스 제품으로 변경을 지시했습니다. Business Logic이 변경된 것이 아니기 때문에 데이터베이스와 Data Access 층만 변경하면 된다고 판단할 수 있습니다. Data Access 층이 오라클에 특화된 인터페이스와 구현 클래스로 구성되어 있고, 만약 Business Logic 층의 서비스 구현 클래스가 Data Access 층의 오라클에 특화된 인터페이스에 의존하고 있다면 쉽게 변경할 수가 없을 것입니다.

그렇지만 다음 그림과 같이 Business Logic 층에서 데이터 처리 인터페이스를 정의하고, 이 데이터 처리 인터페이스는 특정 데이터베이스에 특화되지 않는 일반화된 데이터 처리 메서드, 예를 들면 조회, 저장, 삭제와 같은 단순한 메서드로 구성되게 합니다. 그리고 쇼핑몰의 Business Logic은 단순화된 데이터 인터페이스 메서드를 활용하여 로직 흐름을 처리하게 합니다. 또 Data Access 층은 이 데이터 처리 인터페이스만을 의존하여 특화된 저장소의 데이터 처리를 구현하게 됩니다.

이렇게 하면 Business Logic 층의 서비스 구현체와 데이터 처리 인터페이스의 변경 없이 Data Access 층의 구현 클래스만 변경함으로써 데이터베이스 교체를 쉽게 진행할 수 있습니다. Hexagonal에서 외부의 새로운 타입과의 연계를 위해 어댑터를 추가하는 방식과 동일한 방식입니다.

이런 경우에는 Data Access의 구현체는 일반화된 데이터 처리 인터페이스만 각 저장 기술에 맞도록 충실히 구현하면 됩니다. 따라서 어떠한 데이터 저장소로 변경되어도 상관없이 이 부분만 대체하면 됩니다. 이러한 원리가 Presentation 층에도 비슷하게 적용됩니다.

Presentation Layer는 Business Logic Layer에서 제공한 서비스 API의 결과 값을 어떠한 방식으로 사용자 UI로 전달해주는가만 신경 쓰면 됩니다. Rest API가 될 수도 있고, SOAP이나 다른 프로토콜이 될 수도 있으며, 결과 값으로 XML이나 JSON으로 데이터를 변환해줄 수 있습니다.

Layered Architecture의 Presentation 층과 Data Access 층이 Hexagonal의 외부 영역이 되고, Layered Architecture의 Business Logic 층이 Hexagonal의 내부 영역으로 대응되어 동작될 수 있음을 알 수 있습니다.

반응형