Tier

Layered Architecture 는 레이어 갯수에 따라 3 Tier, 4 Tier 로 나뉜다

4 Tier Layered Architecture

각 티어는 인접한 하위 티어만을 사용 할 수 있다

Presentation Layer 는 Business Layer 만을 사용 할 수 있으며, Business Layer 는 Persistence Layer 만을 다룰 수 있다

Presentation Layer

Presentation Layer 의 관심사는 해당 서버의 사용자에게 어떤 방식으로 표현할 것인지 이다

데이터로 표현되는 api 서버라면 데이터를 어떻게 보여 줄 것인지, 어떤 경로에 어떤 서비스 로직을 태울지를 결정한다.

Web 애플리케이션이라면 Server-Side Rendering, Static Site Generation 을 통해 사용자에게 표현한다

실제로 해당 아키텍쳐를 사용해서 Presentation Layer 를 구성하면 내부 비즈니스 로직은 Business Layer 에서 구현한 비즈니스를 그대로 사용하는 형태로 개발되는데, 이 때 각 레이어의 구분은 명확하게 만들어져야 한다

만일 Database Layer 의 정보가 Presentation Layer 로 넘어온다면 사용자의 변경 요청에 의해 얼마든지 변할 수 있는 Presentation Layer 의 특성이 그대로 Database Layer 에 영향을 미치므로 주의해야 하는 안티 패턴중 하나이다

Business Layer

Business Layer 는 실제 비즈니스 소스가 존재하는 영역이다

각 객체들의 유기적인 협력을 통해 만들어지는 비즈니스는 이 레이어의 관심사라고 할 수 있다.

비즈니스로직을 구동하기 위한 여러 객체들을 만들고 그들이 메시지로 소통하게 만들며, Presentation Layer 에서 사용 할 수 있는 파사드를 만드는게 해당 레이어의  (파사드 패턴)

Presentation Layer 에 노출하는 use case 는 주로 interface 로 만들어지게 되는데, SOLID 를 충족하기 위해서라고 생각한다.
(물론 SOLID 를 모르더라도 객체지향과 유지보수를 생각하다보면 이와 비슷하게 만들어지는데, 해당 내용에 대해 자세히 알고싶다면 이전 글들에서 SOLID 를 설명 한 글이 있으니 참고하면 좋을 것 같다)

이 레이어는 개발자의 자유도가 허용되는 영역으로, 비즈니스 계층을 어떻게 구현하는가 에 따라 여러 방법론들이 존재한다 (물론 Presentation Layer 도 이러한 방법론들이 여럿 있다.)

Persistence Layer

해당 Layer 의 관심사는 '데이터를 어떻게 저장 할 것인가' 이다

실제로 데이터를 어떻게 저장하는지는 해당 레이어의 관심사는 아니다. 정말로 '어떻게' 가 주 관심사 이다.

이 레이어에서는 어떤 데이터베이스에 저장 될 것인지, 어떤 방식으로 저장을 할 것인지 알아서는 안된다.

추상화된 인터페이스를 외부로 노출하고 해당 구현은 이 레이어에 숨긴다. 실제로 이 구현은 여러 저장 방식을 지원하는 형태로 만들어져야 한다.

JDBC, JPA 들이 이 레이어에 속하는데 그들의 관심사 역시 '데이터의 수정, 삭제, 조회, 등록을 어떻게 할 것인가' 에 대해서만 초점이 맞추어져 있다.

Database Layer

Database Layer 의 관심사는 '어디에 저장 할 것인가' 이다

어떤 Database 를 사용하고 어떤 형태로 데이터를 저장 할 것인가. 데이터베이스와 직접적으로 연관이 되어 있으며, 굳이 데이터베이스가 아니라 파일에 저장한다 해도 해당 레이어에서 처리한다

RDBMS, File, NoSQL, GraphQL 등 여러 저장 방식 중 애플리케이션에 맞는 저장 방식을 선택하여 저장하며 영속화된 데이터는 비즈니스를 위해 사용된다

각 레이어에 대한 분류는 사람마다 생각하는 기준이 다를 수 있다고 생각한다

가장 주된 논쟁거리는 '저장' 이라는 행위가 '비즈니스' 에 속하는가 그렇지 않은가 라고 생각한다. 사실 어떻게 바라보느냐에 대한 차이라고 생각해서 정답은 없다고 생각한다. 그저 구현의 차이만 있을 뿐.