계층형 아키텍처 (Layered Architecture) - 지금은 일단 아키텍처 고민할 때가 아니야, 생존부터 해야지

 

스타트업에서 신규 프로젝트가 시작되면

어디서 시작되었는지 모를 스켈레톤 탬플릿으로 코드베이스, 인프라가 뚝딱 나온다.

100이면 100 Layered Architecture였다.

 

몇년 지나면 해당 프로젝트는

'지금은 일단은 아키텍처 고민할 때가 아니야, 생존부터 해야지' 라는 논리로 Layered Architecture가 오남용된다.

Layered Architecture가 무엇이며 잘쓰는 법을 살펴보자

 

1. 계층형 아키텍처(Layered Architecture)란?

• 프로그래밍을 관심사를 기준으로 분리해서 계층 형태로 사용하는 패턴이다.
• 1990년대 중반에 등장한 개념으로 엔터프라이즈급 시스템에서 확장성, 유지보수성 문제를 해결하기 위해 제안됬다.
• 특히 Java, .NET, Oracle, SAP 등의 플랫폼에 본격적으로 채택되며 확산
• 사용자 입/출력 처리, 비즈니스 로직 처리, 데이터 저장소 같은 관심사를 분리해서 설계 시점 유연성, 재사용성, 유지보수성을 목적으로 탄생했다.
• 사실상 업계 표준으로 이해하기 쉽고, 적응이 쉽다.

책 - 클린 아키텍처 : 관심사를 분리하면 DB나 UI는 언제든 교체 가능한 선택을 가질 수 있다.

책 - 클린 아키택처 : 계층 예시

[계층형 아키텍처 - 계층별 설명]

계층	역할	구현 (스프링 기준)
Presentation (=UI, WEB, API)	요청, 응답 반환 책임	@Controller
Business Logic (=Service, Application)	도메인 로직 처리 (Domain Model, Transaction Script)	@Service
Data Access (=Persistence Layer)	DB 직접 통신	@Repository

 

• 제약 조건 :
  • 계층은 같은 계층 또는 하위 계층만 의존할 수 있다. 
  • 하향식으로 의존한다. (ex. Business Logic은 상위 계층인 Presentation Layer를 의존할 수 없다.)
  • 하위 계층이 상위 계층의 존재를 알아서는 안된다.
• 제약 조건을 위반하면, 계층간 결합, 순환 참조가 발생해 코드 복잡도가 기하 급수적으로 늘어난다.
• 아래 예시 의존 방향성은 계층형 아키텍처를 사용한다면 반드시 사수한다.

책 Design it - 개발자에서 아키텍트로

• 단점
  • 계층형 아키텍처는 데이터베이스 주도 설계를 유도한다.
    • JPA 같은 ORM을 사용하면, Entity와 Domain이 결합되어 유연성이라는 품질속성을 잃는다.
    • (그러나, DB를 mysql -> postgress 같은 변경은 실무에서 0%에 가깝다. Entity, Domain 분리는 나중에 해도 늦지 않다.) 

책- 만들면서 배우는 클린 아키텍처

• 지름길을 찾기가 쉽다.
  • 특정 계층에서는 같은 계층 컴포넌트나 아래 계층만 접근 가능한데, 코드에서 강제하는 것이 아니다 보니 사람은 금방 위반하게 된다. 
• 테스트 하기가 어렵다.
  • 규모가 커지면 영속성이 복잡해지면서 종속성을 이해하고, mock하는데에 더 많은 시간을 보내게 된다. 

 

2. 멀티 계층형 아키텍처 (Multi Layered Architecture)

• 2000년대에 접어들면서 Layered Architecture는 3계층(3 tier)의 단점을 보안하기 위해 멀티 계층 패턴(N-tier architecture)으로 진화했다.
• 현업에 대부분 적용중이다. 

 

4계층 아키텍처 

• 마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처에서 설명된 개념이다.
• 위에서 설명한 3계층에서 Domain Layer를 추가한 모습니다.
• 도메인 모델 패턴을 사용해, 재사용성, 유지보수성, 테스트 가능성 품질을 높일 수 있는 전략이다. 

 

[4계층 아키텍처- 계층별 설명]

계층	역할	구현
Presentation	요청, 응답 반환 책임	UI, Controller
Application Service	작업의 흐름, 트랜젝션 조정	Service, Use Case, Application Facade
Domain	Domain Logic	Entity, Domain Service, Aggregate
infra	데이터 저장소, 외부 시스템 연동	Repository, ORM, DAO

조영호님 DDD 강의 - 4계층 아키텍처 강의 슬라이드

N계층 아키텍처 

• 필요에 따라 아래 같은 Layer를 추가한다. 
  • API Gateway
  • BFF(Backend for Frontend)
  • Messaging Layer 
  • 등등.. 
• MSA 형태로 서버가 분리되어도 좋다.
• 유지보수성, 확장성, 테스트 용이성과 같은 품질 속성을 끌어 올릴 수 있다.
• (단, 비용이 따른다. 이래서 리소스 제한이 아키텍처에 영향을 준다.)

 

완화된 계층 아키텍처 

• "계층은 같은 계층 또는 하위 계층만 의존할 수 있다. '는 제약 조건을 완화한 계층형 아키텍처다. 
• 마틴 파울러가 사실상 제약을 완벽히 따르기 어렵다는 것을 시사하며, Presentation에서 Data Access로 바로 의존하여도 괜찮다는 내용이다. (그래도 하향식 의존이라는 큰 틀은 반드시 지켜야한다.)
• 화면 그릴때 필요한 데이터 조회 QueryDsl Repository를 Controller에서 바로 사용하는 것과 같은 경우가 이 경우에 속한다.  

 

결론

• 목표하는 서비스 규모, 품질 속성을 명확히 하자.
  • 규모가 작다면 3계층 아키텍처가 가장 단순하며 충분하다고 생각된다.
• 아키텍처에 정답은 없는데, 제약조건은 정답이다. 반드시 지키자.
  • 계층형 아키텍처를 사용할때는 하위 계층이 상위 계층을 모르게 만들다. 계층형 아키텍처의 핵심이다.
• 팀원들이 계층형 아키텍처 사용법을 위반했을때 잡아낼 방법을 만들자.
  • ArchUnit
  • Spring Modulith
  • 코드 리뷰 문화
• 시스템 복잡도, 요구사항에 따라 멀티 계층 아키텍처를 옵션으로 고려해보자. 

 

 

참고 

- https://jojoldu.tistory.com/603

계층형 아키텍처

- https://herbertograca.com/2016/06/27/peaa-1-layering/?utm_source=chatgpt.com

PEAA.1 – Layering