Layer란 무엇인가
일반적으로 사용되는 layer 구분은 다음과 같다.
- Presentation layer
- Service layer
- Bussiness layer
- Persistence layer
layer를 분리하는 이유
layer를 분리하는 것은 무언가를 추상화하는 것이다.
추상화를 잘하면 각기 다른 계층끼리 부품을 갈아끼우듯 변경할 수 있다
그 말은 즉, 각 layer가 자신의 세부사항을 몰라도 상관없도록 하는 것이 가능하다는 것이다.
또한 layer를 분리함으로써 컴포넌트들의 서로의 의존 계층 관계를 깔끔하게 유지할 수 있다. 서로 관계가 꼬여있는 것이 아니라 위에어 아래로 떨어지는 간단한 구조, 복잡한 참조를 같은 계층 내에서 끝내기 등 깔끔하게 정리 가능하다.
Presentation Layer (UI Layer)
UI 추상화, Web UI, 앱 등 UI가 변경되면 같이 변경되는 layer이다.
Service Layer (Application Layer)
Domain Model을 묶어서 이 소프트웨어에서 사용 가능한 핵심 작업 집합을 수행하는 계층이다.
다시 말해 이 소프트웨어가 수행해야 하는 작업과 이 소프트웨어에게 내릴 수 있는 명령을 명시한다.
Domain Model 의 비즈니스 로직과 Service Layer가 혼동될 수 있는데,
비즈니스 로직은 주로 Entity 내에서의 단순 연산을 다루고 따라서 비즈니스 로직을 호출하는 것만으로는 복잡한 작업을 처리할 수 없다
반면 Service Layer는 도메인 모델 여러개를 불러와 요청을 가공하고 비즈니스 로직을 호출하고 응답을 조정해서 또 다른 비즈니스 로직을 호출하고 하는 등 종합적으로 비즈니스모델과 도메인을 갖고 와 소프트웨어가 수행해야하는 기능을 수행한다.
따라서 여러 비즈니스 로직들을 의미있는 수준으로 묶어서 제공하는 것이 Service Layer의 역할이다.
물론 별도의 캡슐화가 필요하지 않은 경우에는 도메인 모델 기능을 그대로 서비스로 만들 수도 있지만,,,
여튼 결국 Service Layer는 핵심에 가까운 API를 제공하는 계층이다.
Controller는 UI Layer에 가까워서 입력과 아웃풋을 처리한다.
따라서 요청이 UI를 통해 들어온거라면 Controller를 거치겠지만 다른 경로로 들어왔거나 내부 API의 호출이면 Controller를 거치지 않고 Service Layer만으로 해결할 수 있다.
단, 핵심 로직은 Business Layer(Domain Model)에 두고 Service Layer는 얇게 유지하는게 맞다.
Bussiness Layer (Domain Layer)
쉽게 말해 Data와 그와 관련된 비즈니스 로직 메서드를 가지고 있는 객체이다.
Domain Model 클래스에 필드와 Getter, Setter만 두고 단순 DTO처럼 활용하면서 로직은 다 Service에 두는 것은 바람직하지 않다.
객체라는 건 data 및 그와 연관된 logic을 가지고 있는 기본 단위다.
따라서 단순 요청/응답/전달을 위한 DTO와 비즈니스로직에서 사용하는 actor 그 자체인 Model 클래스는 다르게 바라보는 것이 좋다.
Model: User(Actor 그 자체)
DTO: UserRequest / UserResponse
무엇이 Presentation Layer고 무엇이 Service Layer냐?
UI에 종속적인 로직인지 아니면 그 소프트웨어의 핵심 API 로직인지 생각해본다.
생각하는 기준은 간단하다. 만약 지금의 UI가 다른 방식으로 변경된다고 할 때 그 어떤 방식으로 변경되더라도 제공되는/받는 정보가 계속 일치할 것인지를 따져보면 된다.
예를 들어 계좌 정보와 카드 정보를 동시에 표시하는 web UI를 제공하고 있었는데 이를 app UI로 변경하는 상황을 생각해보자.
바뀐 app UI에서도 여전히 계좌 정보와 카드 정보를 동시에 제공할 것이다. 만약 진짜 카드 정보와 계좌 정보를 묶어서 반환하는걸 모든 인터페이스에서 핵심 api로 제공한다면 이것은 service Layer에서 구현한다.
그것이 아니라면 Presentation Layer에서 구현하면 된다.
layer 분리 : MVC 디자인 패턴
MVC 패턴은 Presentation code 와 나머지 code를 어떻게 잘 분리할 것이냐에 대한 패턴이다.
Controller의 역할
Controller는 UI layer 바로 다음에 위치한 non-user interface object로 input system event를 받는 역할을 한다.
즉,
UI로부터 사용자의 input(request)를 받아서
어떤 service Layer api를 호출해서 결과를 가져올지 결정하고
어떤 UI에 그 결과를 전달할 지 결정한다.
Controller 는 Presentation Layer
이 부분은 논란이 좀 있으나 Controller 는 Presentation Layer에 가깝다고 생각한다.
일단 Controller는 때때로 View가 수행하지 못하는 Presentation 로직을 처리하기 위해서라도 Presentation Layer에 있는 것이 맞고
애초에 MVC 분리 자체가 Controller를 Presentation Layer로 보고 있고
UI를 변경할 때 Controller 하나가 아예 제거되거나 변경되기도 하기 때문이다.
