Layered architecture

dev_dong·2024년 12월 19일

도메인 : 사용자가 사용하는 것이며, 소프트웨어로 해결하고자 하는 문제 영역을 의미함.

(DNS와 같은 도메인관 약간 의미가 다름) → 소프트웨어가 어떤걸 해결할지.

각각의 기능적인 문제에 영역들을 정의하는 도메인과 그 도메인을 사용하는 비지니스 로직을 중심으로 설계하는 것을 말함.

이러한 방식에는 몇가지 특징이 있음.

1, 데이터 중심이 아닌, 도메인의 모델과 로직에 집중하는 것이며

2, 동일한 표현과 단어로 구성된 단일화된 언어체계를 사용함 Ubiquitous Language, 보편적 언어 사용 → 신규회원 등록, 신규회원 추가 와 같이 애매한 단어가 아닌 업무 용어를 통일하여 소통함

3, software entity와 domain간 개념의 일치 → 분석 모델과 설계가 다르고, 그것과 코드가 다른 구조가 아닌, 도메인 모델부터 코드까지 항상 함께 움직이는 모델을 지향하고 있음.

이러한 디자인 방식은 레거시 서버가 있어 이미 큰 틀과 검증된 플로우가 있을 때,

이것을 전체적으로 한 번에 갈아엎는 빅뱅 방식 대신, 필요한 기능을 조금씩 구별하고 그것에 대해 필터링 하여 개선하는 점진적인 향상을 선택할때 유리함

사람이나 시간과 같은 리소스를 조금 더 유연하게 관리가 가능함

layered 아키텍처는 코드의 아키텍처를 구성할 때 주로 사용되며, 일반적으로 3~4계층으로 나누어 사용함.

3계층은 표현계층(Presentation Layer) - 서비스 계층 (Business Layer) - 영속성 계층(Persistence Layer)로 나누어 사용하곤 함.

DDD 를 이용할 때도 이에 대응되는 계층적인 구조가 있음.

대충 계층 구조는 아래와 같이 잡음.

위에 있는 계층에서는 아래 이는 계층에 접근이 가능하지만, 아래에서 위로는 불가능 한것을 기본으로 하고 있음.

사용자 인터페이스 UI(표현 계층)

어플리케이션과 연결되며, 인아웃풋 관련 통신 변환 등을 담당함.

위 도메인 객체를 직접적으로 사용하면서 어떻게 사용할지를 정의하는 유스케이스를 실제로 구현함.

소프트웨어가 비지니스 로직을 정의하고 정상적으로 수행될 수 있도록 도메인 계층과 인프라스트럭처 계층을 연결해주는 역할
이 계층은 많은 정보를 가지도 있지 않게 하는 것이 중요함 (실질적인 데이터의 상태 변화 등의 처리는 도메인 계층에서 진행할 수 있도록 위임하는 것이 중요함.)
응용계층에서 진행하는 일은 일반적으로 아래와 같음
- 트랜잭션의 단위
- DTO 변환
- Entity 조회/저장 (구현은 infra)
- 사용자 인증/인가 (URL 만으로는 판단이 어렵거나, DB 내의 데이터와 대조해봐야 알 수 있는 경우 ex.데이터 존재 여부, 중복 여부 등)
- 파라미터 검증 (presentation layer에서도 할 수 있지만, 주로 presentation layer는 요청 방식에 따라 달라지는 ‘형식’에 대한 검증을 하고, application layer에서는 ‘논리적’인 오류를 검증함.)