layered / hexagonal architecture

layered architecture

layered architecture는 가장 일반적인 아키텍처 패턴이다.

대부분의 Java 애플리케이션에 대한 표준으로 널리 알려져 있기도 하다.

 

널리 알려진 이유는 많은 회사의 조직 구조와 밀접하게 일치하기 때문일지도 모른다.

 

layered architecture는 수평 계층으로 구성되며, 각 계층은 특정 역할을 수행하도록 설계한다.

 

많은 방법이 있겠지만 지금은 4가지의 계층으로만 표현을 해보겠다.

 

 

1. Presentation Layer(프레젠테이션 계층)은 모든 사용자의 인터페이스 및 브라우저 통신을 처리

2. Business Layer(비지니스 계층)은 요청과 관련된 특정 비즈니스 규칙을 실행

3. Persistence Layer(지속성 계층)은 데이터를 저장하고 관리

4. Database Layer

 

아키텍처의 각 계층은 특정 비즈니스 요청을 충족하기 위해 수행해야 하는 작업을 중심으로 추상화를 형성한다.

 

예를들면, 프레젠테이션 계증은 고객에게 노출만 시켜주면 되기 때문에 내부 상황을 알 필요가 없다.

비즈니스 계층은 데이터의 형식이나 출처에 대해 신경쓸 필요가 없다.(지속성 계층을 통해 확인하기 때문)

 

 

layered architecture의 핵심은 관심 분리이다.

 

각 계층은 관련한 일만 수행하며, 다른 계층의 일에는 일체 간섭하지 않는다.

이렇게 하면 효과적으로 책임과 열할을 나눌 수 있게되며, 애플리케이션의 개발, 테스트, 유지보수를 용이하게 한다.

 

 

또 하나 중요한 점은, 위 그림에서 화살표는 한 곳에서 특정한 곳으로의 이동밖에 승인하지 않는다.

이것은 layered architecture에서 매우 중요한 개념이다.

 

프레젠테이션 계층에서 요청이 시작되면 데이터베이스 계층까지 가기위하여 비지니스 계층과 지속성 계층을 거치게 된다.

 

프레젠테이션 계층이서 바로 지속성 계층이나 데이터베이스 계층으로의 접근을 왜 막는 것일까?

어떠한 작업을 하기 위해 바로 처리를 하지 못하고 몇 번의 계층을 거쳐야 한다는 것이 상당히 비효율적으로 보일 수 있다.

 

그러나, 격리 계층이라는 말에 핵심이 있었다.

 

격리 계층이라는 것은 아키텍처의 한 계층에서 수행된 변경이 다른 계층의 구성 요소에 영향을 주면 되지 않는다는 의미를 포함한다.

 

만약 프레젠테이션 계층에서 지속성 계층에 대한 접근을 허용하게 된다면, 지속성 계층 내에서 SQL에 대한 변경 사항이 비지니스 계층과 프레젠테이션 계층 모두 영향을 주게 되므로 상호간 의존성이 늘어나는 시스템이 되어 버린다.

 

이렇게 된다면, 당장은 편하겠지만 유지보수에 상당한 어려움이 따를 것이다.

 

 

개발자의 입장에서도 각 계층을 확실하게 구분짓는것이 좋다.

(다른 계층이 어떻게 동작하는지 알 필요가 없으니까)

 

특정 부분에서는 이러한 부분을 의도적으로 접근을 허용하기도 하긴 한다.(이 부분까지는 하지 않겠다)

 

정리

만약, 어떤 패턴을 사용할 지 모르겠다면 layered architecture을 사용하는 것을 추천한다.

가장 범용성이 넓으며, 대부분의 서비스에서 활용할 수 있기 때문이다.

 

그리고 layered architecture는 모놀리식 애플리케이션에 적합한데, 왠만하면 문제가 되지 않겠지만 배포나 안정성, 성능 및 확장성에 잠재적인 문제를 가지고 있을 수 있다.

 

마지막으로 layered architecture는 변화에 약한 편이고 배포하는 것에서 스마트하지가 않다.(성능과 확정성이 낮다는 뜻)

그러나, 각 계층에 대한 테스트를 하기가 쉬우며 그만큼 복잡하지 않기 때문에 개발하기 용이하다.

 

참고 : https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html

Software Architecture Patterns

 

 

hexagonal architecture

Hexagonal Architecture(육각형 설계)는 포트와 어댑터 설계라고도 한다.

 

이러한 육각형 설계는 인터페이스나 기반 요소의 변경에 적게 영향을 받는 쪽으로 설계하는 것이 목표이다.

 

Hexagonal Architecture가 전통적인 설계보다 좋은 점은, 인터페이스를 다중화하더라도 변경되는 코드가 거의 없으며, 많은 코드 공유를 통해서 재사용도 높일 수 있다.

 

다시 말하자면, 이러한 구조로 설계를 하면 인터페이스나 기반 요소가 사용자의 요구사항 혹은 수용 능력에 영향을 받아서 변경되더라도 애플리케이션 동작(도메인 로직 혹인 비즈니스 로직)에는 영향을 주지 않는다.그만큼 돔인 로직이 견고해지며 소프트웨어의 지속 가능성을 높일 수 있다.

 

Hexagonal Architecture를 포트와 어댑터 설계라고 부르는 이유가 있다.

 

딱봐도 포트와 어댑터라고 힌트가 나와있는데, 포트는 인터페이스라고 생각하면 된다.

예를 들면, 클래스의 메서드 시그니처나 Java의 인터페이스이다.

어댑터는 디자인 패턴에서와 같이 클라이언트에 제공해야 할 인터페이스를 따르면서도 내부 구현은 서버의 인터페이스로 위임하는 것이다.

 

포트의 역할은 변경이 잦은 어댑터와 애플리케이션의 결합도를 낮추는 것이다.

애플리케이션은 핵심 로직에 가깝기 때문에 결합도를 낮추는 것이 상당히 중요하다.

 

그리고 애플리케이션은 도메인에 의존하지만 도메인은 애플리케이션과 어댑터에 의존하지 않는다.

즉, 애플리케이션이나 어댑터가 변경되어도 핵심 로직인 도메인은 아무런 영향을 받지 않는다.

 

글로만 보면 이해가 잘 되지 않으니, Hexagonal Architecture를 검색해봐서 많은 사람들이 작성한 설계를 보면서 이해하는 것이 좋다.