MSA, Software Architecture : Layered Architecture

 

 

 

 

 

 

MSA에서 Software Architecture로 사용하는 것은 Hexagonal Architecture와  Layered Architecture 등이 있는데 그 중에서 Layered Architecture에 대해 알아보자

 

 

 

 

 

Layered architecture란?

layered architecture란 말 그대로 계층이 나뉘어져 있는 아키텍쳐를 뜻한다. layered architecture의 주된 목표는 어플리케이션을 여러 개의 굵직한 횡단 관심사(cross-cutting concern)로 분리해, 각각의 layer는 하나의 관심사에만 집중할 수 있도록 하는 것이다. 각각의 layer에 대한 명칭은 출처마다 조금씩 다르지만 근본적인 역할과 목적은 같으며, 대표적으로 DDD(Domain Driven Design)에서는 아래와 같은 구조의 layered architecture를 소개하고 있다.

요약
소프트웨어 아키텍쳐중 하나의 패턴, 계층별로 구조화
각각의 layer는 하나의 관심사에 집중
단방향으로 의존성을 갖는다.

 

 

 

 

PRESENTATION
• 인터페이스 계층 (Interface layer)
• client 와 communication 을 위한 interface
• 서비스 성격에 따라 web, api, message, batch

APPLICATION
• 서비스 계층 (Service layer)
• 고수준으로 추상화된 service(특정 행위 추상화) 객체 배치
• 시나리오에 따른 도메인 로직 호출
• 서비스 트랜젝션 관리

DOMAIN
• 비지니스(도메인) 로직 관리
• 핵심 layer

INFRASTRUCTURE
• 영속 계층 (Persistence layer)
• technical part, 세부 기술
• 서비스 및 비지니스와 구현기술 분리
• DIP(Dependency Inversion Principle, 의존성 역전의 원칙) 로써 다른 layer에서 기술이 주입됨

 

 

 

 

 

 

Presentation Layer
• API 서버의 Controller 관련 영역에 해당한다. 
• 외부로 노출되는 Interface(CRUD) 들에 대한 정의, Response와 연관된   Component들을 위한 Layer 이다.


Application Layer
• 각 Domain별 데이터를 기반으로 실제 Response를 위한 Business 로직에 대한 구현 및 이와 연관된 Component들을 위한 Layer 이다. 
• 단일 도메인의 데이터를 단순히 Read만 하는 API의 경우 특별한 동작이 없는 Layer가 될 수도 있다.
 

Domain Layer
• 해당 MicroService의 Domain 뿐만 아니라, 타 Domain 데이터를 제공해주는 Service를 구현해주는 Layer 이다.
• 실제 데이터를 접근 하는 Interface를 정의하게 되며, 타 Layer와의 의존성이 없게 된다.
• 각 Domain의 데이터는 가져오게 되며 이를 수행하는 Interface를 Infrastructure layer에 제공하고, 이들의 구현체를 Spring을 통해 주입 받게 된다.
• Domain Layer는 해당 데이터가 Inner call, DB access, 기타 Cloud resource 어디로 부터 가지고 오는 지에 대한 정보는 모르게 된다.
 

Infrastructure Layer
• Domain으로 부터 제공받은 Interface를 구현하는 Layer 이다.
• Interface의 요청에 맞게 Repository, Http call, AWS resource 접근을 하여 데이터를 올려보내주는 역할을 하는 Component들을 구현해두는 Layer 이다.

 

 

 

기본 설계 원칙
• 서비스의 Java코드 최상위 Package는 4개의 Layer만 존재해야한다.
• 각 Layer는 양방향 참조가 발생하지 안도록 관리되어야 한다.
• 모든 Layer는 1단계 Layer에 대해서만 Dependency를 가지도록 한다.
• Layer간 Data transfer를 위해 정의된 Class는 DTO로 정의 한다.

 

 

 

 

 

 

장점
• 유지보수성

   ∘ (관심사가 분리되어) 개발변경 영향도 낮음
• 재사용성

   ∘ 모듈별 배포 편이성
   ∘ 서비스 확장성
• 개발 생산성

   ∘ (관심사가 분리되어) 서비스 추상화에 따른 가독성 증가
   ∘ 비지니스 로직과 기술로직의 의도적 분리로 테스트 향상

 

단점
• 컨벤션 준수에 따른 제약
   ∘ 간단한 시나리오라도 boilerplate 필요
   ∘ layer 간 호출로써, 보다 많은 클래스 생성

 

 

 

 

DOMAIN Layer와 INFRASTRUCTURE  
Crossing boundaries
제어의 흐름은 원의 내부에서 외부로 향할 수 있는데 소스코드의 의존성은 이렇게 될 경우 의존성 규칙을 위배하게 되므로, 의존성 역전의 원칙을 이용하여 이를 해결해야 한다는 이야기이다. 이는 조금더 풀어서 이야기하면 고수준의 정책은 저수준의 정책에 의존해서는 안된다는 이야기이다.

간단한 예를 통해 알아보자. 일반적으로 조회 요청이 일어나면 이를 처리하기 위해 제어의 흐름과 소스코드의 의존성은 아래와 같다.

source-code-dependecy
이러한 제어의 흐름과 같이 소스코드 의존성을 가지게 된다면 Service가 구체적인 RDBMS를 구현한 구현체(저수준의 정책)를 직접 참조하게 되는데 이는 의존성 규칙을 위반하게 된다. 이러한 문제의 가장 간단한 해결책은 DIP를 적용하는 것이다.

source-code-dependecy
추상화된 Repository 인터페이스를 두어서 Service가 이를 참조하고, 구체적인RDRepository가 이러한 인터페이스를 구현하게 된다면 소스코드의 의존성을 역전시킬 수 있다. 이러한 DIP를 통해 우리는 Service는 DB의 구체적인 세부사항을 알 필요도 없고, DB의 변경에도 영향을 받지 않게 된다.

 

 

 

 

 

 

 

출처

 

https://velog.io/@jeb1225/DDD%EC%9D%98-%EA%B3%84%EC%B8%B5%EA%B5%AC%EC%A1%B0Layered-architecture

 

https://techblog.woowahan.com/2647/