오래된? Layered Architechture

Layered Architecture란?

Layered Architecture는 애플리케이션을 기능과 책임에 따라 계층으로 분리하는 설계 패턴입니다. 각 계층은 특정 역할을 수행하고, 계층 간의 의존성을 명확히 하여 유지보수와 확장성을 높입니다.

---

1. 3Layer Architecture (3계층 아키텍처)

3-Layer Architecture는 과거부터 널리 사용된 계층형 아키텍처로, 시스템을 세 가지 주요 계층으로 나눕니다.

구성

1. Presentation Layer (UI Layer)
   • 사용자와 상호작용하는 부분입니다.
   • 화면, 웹 컨트롤러, REST API 등의 역할을 합니다.
   • 예: Controller, View
2. Business Logic Layer (Service Layer)
   • 비즈니스 로직을 처리하고 애플리케이션의 핵심 동작을 담당합니다.
   • 데이터의 흐름과 로직을 관리하며, Data Access Layer와 연결됩니다.
   • 예: Service 클래스
3. Data Access Layer (Persistence Layer)
   • 데이터베이스와 통신하며 데이터를 저장, 조회, 수정, 삭제합니다.
   • DAO(데이터 접근 객체) 또는 Repository 패턴을 사용합니다.
   • 예: Repository, DAO

---

3-Layer 구조의 흐름

[Presentation Layer] → [Business Logic Layer] → [Data Access Layer]

특징

• 단순하고 직관적: 각 계층이 명확히 구분되기 때문에 이해하기 쉽습니다.
• 비즈니스 로직 집중: 로직이 Service Layer에 집중됩니다.
• 유지보수 문제: 로직이 커질수록 Service Layer가 비대해져서 유지보수가 어려울 수 있습니다.
• 도메인 모델이 빈약: Entity는 데이터를 보관하는 단순한 데이터 객체로 사용됩니다.

---

2. 4Layer Architecture (4계층 아키텍처)

4-Layer Architecture는 3-Layer 구조를 확장한 형태입니다. Application Layer를 추가하여 비즈니스 로직의 흐름과 핵심 로직을 분리합니다.

구성

1. Presentation Layer
   • 사용자 요청을 받고 응답을 반환합니다.
   • 예: Controller, View
2. Application Layer (Service Layer)
   • Use Case를 조율하는 역할을 합니다.
   • 도메인 로직을 호출하고 데이터의 흐름과 비즈니스 규칙을 관리합니다.
   • 예: Service 클래스
3. Domain Layer
   • 핵심 비즈니스 로직을 담당합니다.
   • 엔티티(Entity), 값 객체(Value Object), 도메인 서비스(Domain Service) 등을 포함합니다.
   • 예: Car, CarDomainService
4. Infrastructure Layer
   • 데이터베이스 접근, 외부 시스템 연동, 기술적 세부사항을 처리합니다.
   • Repository 패턴, API 클라이언트 등이 여기에 위치합니다.
   • 예: Repository, JPA, API Client

---

4-Layer 구조의 흐름

[Presentation Layer] → [Application Layer] → [Domain Layer] → [Infrastructure Layer]

특징

• Application Layer 추가: 비즈니스 흐름과 도메인 로직을 조율하는 계층이 생겼습니다.
• Domain Layer 강화: 핵심 비즈니스 로직이 Domain Layer로 이동하여 도메인 모델이 리치 모델(Rich Domain)이 됩니다.
• 책임 분리 명확: Application Layer와 Domain Layer가 분리되면서 코드가 더 명확하고 유지보수하기 쉬워졌습니다.

---

3. 3-Layer와 4-Layer의 비교

비교 항목	3-Layer Architecture	4-Layer Architecture
계층 수	3계층 (Presentation, Business Logic, Data Access)	4계층 (Presentation, Application, Domain, Infrastructure)
Application Layer	없음. Service Layer가 모든 비즈니스 로직을 담당	Use Case 흐름을 조율하며 도메인에 위임
Domain Layer	빈약한 도메인 모델 (Anemic Model)	풍부한 도메인 모델 (Rich Domain Model)
비즈니스 로직 위치	Business Logic Layer(Service)에 집중	Domain Layer에 위치, Application은 흐름 조율
책임 분리	상대적으로 덜 명확	계층별 책임이 명확하게 분리됨
유지보수	로직이 커지면 Service가 비대해짐	각 레이어가 분리되어 유지보수와 확장성 용이
적용 사례	작은 규모, CRUD 중심 시스템	복잡한 비즈니스 로직, 확장성이 필요한 시스템

---

4. 결론

3-Layer Architecture

• 간단하고 직관적인 구조로, 작은 규모의 애플리케이션이나 CRUD 중심 시스템에 적합합니다.
• 하지만 로직이 커질수록 Service Layer가 비대해져서 유지보수가 어려워질 수 있습니다.

4-Layer Architecture

• 복잡한 비즈니스 로직이 존재하거나 대규모 시스템에 적합합니다.
• Application Layer와 Domain Layer의 분리를 통해 책임 분리가 명확해지며 유지보수와 확장성이 뛰어납니다.
• DDD(도메인 주도 설계)와 잘 어울리는 구조입니다.

---

언제 무엇을 선택해야 할까?

1. 작고 단순한 애플리케이션:
   • 3-Layer Architecture로도 충분합니다.
   • 예: 간단한 CRUD 시스템, 프로토타입 개발
2. 복잡한 비즈니스 로직과 확장성 필요:
   • 4-Layer Architecture를 선택하세요.
   • 도메인 모델이 강화되고 책임이 분리되어 확장성과 유지보수성이 뛰어납니다.

요약: 4-Layer Architecture는 3-Layer의 발전형이며, 현대적이고 복잡한 시스템에서는 4계층 구조가 더 적합합니다. 😊