I. 개요

Layered Architecture는 소프트웨어 개발에서 가장 일반적으로 사용되는 구조이다. 각 Layer는 어플리케이션 내에서 역할과 관심사에 따라 구분된다. 이를 Seperation of Concern이라고 하며, 특정 Layer의 구성요소는 해당 Layer에 관련된 기능만 수행한다. 이러한 특징 덕분에 Layered Architecture는 높은 유지보수성을 지니며, 간편하게 테스트를 시행해볼 수 있다.

Layered Architecture는 Layer의 구성에 따라 N-Tier Layered Architecture이라고 이야기한다. Layer의 분리를 몇 단계로 구성할지는 프로젝트마다 상이하며, Layer간의 결합도, 도메인 로직의 분리 등 많은 이유에서 구조가 달라진다. 이에 따라, 대표적인 두 가지 Layered Architecture를 분석해보면서 이해해보도록 하겠다.

💡 구조가 워낙 다양하다보니, 내용에 일정 부분 비약이 있을 수도 있다. 좀 더 공부하고 알게되면, 정확하지 않은 내용은 수정이 필요하다.

II. 3-Tier Layered Architecture

1. Presentation Layer

• 사용자와 상호작용을 처리하는 Layer
• CLI, HTTP 요청, HTML 처리 등을 담당한다.
• HTTP 요청 처리 및 HTML 렌더링을 담당한다.
• MVC(Model, View, Controller)도 이 Layer에 속한다.
• Spring에서는 @Controller 어노테이션을 이용해 명시한다.

2. Domain(Business/Service) Layer

• 서비스/시스템의 핵심 로직을 담당한다.
• 유효성 검사 및 계산을 포함하는 Business 논리 계층이다.
• 어플리케이션이 수행해야하는 도메인과 관련된 작업을 담당한다.
• 입력/저장된 데이터를 기반으로 계산한다.
• Presenataion 계층에서 받은 데이터의 유효성을 검사한다.
• Spring에서는 @Service 어노테이션을 통해 명시한다.

3. Data Access(Persistance) Layer

• 데이터베이스 또는 원격 서비스에서 영구 데이터를 관리하는 방법을 분류하는 데이터 접근 계층
• DB 혹은 DB Source는 서버 외부에 별개로 존재하는 것이 일반적이기 때문에, 이러한 Data와의 소통을 표현해주는 계층이라고 할 수 있다.

III. 4-Tier Layered Architecture with DTO

✅ https://github.com/JeekLee/Post_API

이번에 간단한 API를 구성할 때 사용했던 구조이다. DTO는 Domain(Entity) Layer와 무관하게 데이터 전달만을 위한 객체이다. DTO 객체가 없는 경우, Domain객체에 대해 다음과 같은 문제가 발생할 수 있다.

1. Presentation 영역에서 필요한 로직과 Domain 로직을 분리할 수 없다.
   • ex) 화면 노출을 위해 LocalDateTime을 원하는 형식의 String으로 변경하는 로직이 Domain 객체 안에 들어가야 하는 경우가 생길 수 있다.
2. 외부 API 제공에 Domain 객체가 사용되어야 할 경우, Public으로 선언되는 로직이 새로 포함되어야할 수도 있고, 많은 영역에서 Domain이 접근하게 된다.

결론적으로, DTO로 Domain 객체를 캡슐화함으로써, Domain 객체의 신뢰성을 높이고 자유롭게 활용하기 위해서 이러한 구조를 사용했다.

IV. 정리

시대가 바뀌고 프로그래밍의 패러다임이 변화함에 따라서, 선호되는 구조 역시 시시각각으로 바뀔 수 밖에 없다. 이번에 DTO를 사용해 API를 구성할 때 ResponseDTO와 RequestDTO로 CRUD를 전부 구현했었는데, 다형성의 측면에서 너무 DTO와 Entity가 강하게 결합되어 있다는 얘기를 들었었다. 프로젝트의 방향성에 따라, 개념을 이해하고 활용하는 것이 가장 중요한 것 같다.