[아키텍처] 계층형, MVC, 마이크로서비스, 헥사고날 아키텍처, 장단점

계층형 아키텍처

• controller, web: 웹 계층
• service: 비즈니스 로직, 트랜잭션 처리
• repository: JPA를 직접 사용하는 계층, 엔티티 매니저 사용
• domain: 엔티티가 모여 있는 계층, 모든 계층에서 사용 | 비즈니스와 관련된 도메인 로직 처리, 도메인을 조작하기 위한 모든 것

계층형 아키텍처와 수직 계층

1. 프레젠테이션 계층 (Presentation Layer)
   • 사용자와의 인터페이스(UI)를 담당하는 계층
   • 주로 컨트롤러(Controller)와 뷰(View)로 구성
   • 사용자의 요청을 처리하고, 결과를 화면에 출력
   • MVC를 사용하여 쉽게 구현 가능
2. 비즈니스 계층 (Business Layer)
   • 비즈니스 로직을 처리하는 계층
   • 주로 서비스(Service)로 구성
   • 사용자의 요청을 받아서 비즈니스 로직을 처리하고, 데이터를 저장하거나 조회한다.
   • 도메인 모델을 구성할때는 Service Layer를 두는것이 바람직하다.
3. 데이터 액세스 계층 (Data Access Layer)
   • 데이터를 저장하고 조회하는 계층
   • 백엔드의 DB나 레거시 시스템과 연동하는 인터페이스 역할을 하는 계층
   • 주로 리포지토리(Repository)로 구성
   • 데이터베이스와의 상호작용을 담당
   • JPA 등으로 쉽게 구현할 수 있다.

MVC (Model-View-Controller) 아키텍처

• 사용자 인터페이스와 비즈니스 로직, 데이터 저장소 등을 분리하여 각각의 역할을 독립적으로 수행하도록 구성하는 방식

1. Model (모델): 애플리케이션의 비즈니스 로직과 데이터 저장소를 담당
2. View (뷰): 모델의 결과를 시각적으로 보여주는 역할
3. Controller (컨트롤러): 사용자의 요청을 받아서 모델과 뷰를 연결하는 역할

계층형 아키텍처의 장단점

장점

• 중간에 구조를 바꿀때 해당 부분만 바꾸면 된다. = 유지보수가 쉽다.

단점

• 결합도가 높아진다.
  • 각 계층이 서로 의존하고 있기 때문에, 한 계층에서 발생한 변경사항이 다른 계층에 영향을 미칠 수 있다. (유지보수 어려워짐)
• 복잡성이 증가한다.
  • 계층이 많아질수록 시스템의 복잡성도 증가 (계층마다 데이터를 전달하고 처리하는 데 필요한 로직이 많아지기 때문)

계층형 아키텍처는 데이터베이스 주도 설계를 유도한다?

• 전통적인 계층형 아키텍처의 토대는 데이터베이스이므로 웹 계층은 도메인 계층에, 도메인 계층은 영속성 계층에 의존하기 때문에 자연스레 아키텍처 전체가 영속성 계층, 즉, 데이터베이스에 의존하게 된다.
• 결국 우리는 비즈니스 로직인 도메인이 중심이 되어야 하는데, 이것이 문제가 될 수 있다.
• 데이터베이스 중심적인 아키텍처를 구성하게 되면 엔티티가 레포지토리의 결합성이 너무 커진다.

이를 보완하기 위해 등장한 아키텍처들을 알아보자

마이크로서비스 아키텍처

• 하나의 시스템을 여러 개의 작은 서비스 단위로 분리하여 개발하고, 각각의 서비스는 독립적으로 배포, 확장, 운영할 수 있도록 구성
• 자체 데이터 스토리지를 가지며, 서비스 간의 통신은 API를 통해 이루어짐

장점

• 높은 유연성과 확장성
  • 각 서비스가 독립적으로 개발, 배포, 운영되기 때문에 시스템 전체의 유연성과 확장성이 높아짐
• 낮은 결합도와 높은 응집
  • 각 서비스는 독립적으로 개발되기 때문에, 각 서비스는 서로 결합도가 낮고 응집도가 높음(유지보수 쉬워짐)
• 다양한 기술 스택 사용 가능
  • 각 서비스는 독립적으로 개발되기 때문에, 각 서비스에서 다른 기술 스택을 사용 가능

그럼 마이크로서비스 아키텍처의 단점이 있을까?

• 복잡성 증가
  • 여러 개의 서비스로 분리되어 있기 때문에, 각 서비스 간의 통신, 데이터 일관성 등의 문제를 고려
• 초기 비용과 테스트 및 운영 상대적으로 어려움

헥사고날 아키텍처

• 포트와 어댑터를 중심으로 구성된 아키텍처
• 소프트웨어를 내부적인 도메인(비즈니스 로직, 데이터 모델)과 외부적인 요소로 분리
• 포트와 어댑터를 통해 내부적인 도메인은 외부 시스템과의 연결에 대한 구체적인 구현과는 분리 → 유지보수 향상, 유연성 증가

구성

1. 도메인 영역: 비즈니스 로직을 담당
2. 인프라스트럭처 영역: 데이터베이스, 외부 시스템과의 상호작용 등을 담당
3. 어플리케이션 영역: 도메인과 인프라스트럭처 영역을 연결하는 인터페이스 역할

헥사고날 아키텍처도 데이터베이스 주도 설계를 유도하는 거 아니야?

• 맞다. 그러나 헥사고날 아키텍처는 계층형 아키텍처와 달리 의존성 역전 원칙(DIP)에 기반을 두고 있어서 이 문제를 해결할 수 있다.
  • 의존성 역전 원칙 : 상위 수준 모듈이 하위 수준 모듈에 의존하지 않도록 하고, 추상화된 인터페이스나 추상 클래스를 통해 상호작용하도록 하는 원칙
• 내부 도메인이 외부 요소에 의존하지 않는 대신, 외부 시스템과의 연결을 담당하는 포트와 어댑터가 내부적인 도메인에 의존
• 따라서 모듈 간의 의존성을 낮추고 유연성을 높일 수 있다.

추가로, 의존성 역전 원칙이 있는 SOLID에 대해 더 궁금하다면 아래를 참고하자!

https://0m1n.tistory.com/3

[스프링 핵심 원리] 객체 지향 설계의 5가지 원칙(SOLID), 스프링