클린 아키텍처

회사에서 클린 아키텍처 구조를 사용하고 있는데 공부할 겸 간단하게 정리해보려고 한다  .. 

 

클린 아키텍처 

 

클린 아키텍처는 '추상화 개념'으로써 관심사를 분리시키고 의존도를 낮추는 것에 목적을 둔 아키텍처이다. 

이렇게 했을때의 이점은 의존도를 낮추고 서로에게 주는 영향을 감소함으로써 유지보수의 용이성을 향상시킨다. 

 

기본적인 원리는 종속성 규칙(Dependency Rule)을 지키는 것이다. 각 코드의 종속성은 외부에서 내부로 안쪽으로만 가리킬 수 있고, 고수준 정책(High level policy)이 저수준 정책(Low level policy)의 변경에 영향을 받지 않도록 하는 것이다.

 

여기서 의미하는 수준(Level)은 입/출력과의 거리를 의미하는 것으로,
고수준 정책은 보통 UI 또는 인터페이스와 거리가 먼 비즈니스 영역 Business Rules, Entities 등을 의미하며,
저수준 정책은 위와 반대로 거리가 가까운 인프라 영역이나 UI 영역 Presentation, Controllers 등을 의미한다.

 

클린 아키텍처 구조

**안쪽에 위치할수록 고수준 정책, 바깥쪽에 위치할 수록 저수준 정책

 

엔티티 (Entities)

의도에 따라 도메인 계층으로도 불리며, 엔티티 계층은 하나 이상의 프로그램 간에 공유될 수 있다는 가정하에 만드는 수명이 긴 객체이다. (즉, 재사용의 가능성이 높다는 것을 인지하고 외부에 의해 변경될 가능성을 낮추어야 합니다.) 이곳에는 Enterprise 규모의 비즈니스 데이터를 포함하거나 핵심이 되는 비즈니스 규칙을 캡슐화한다.

 

Entity & Dto

** Entity

 

Entity 클래스는 실제 DB 테이블과 매핑되는 핵심 클래스로, 데이터베이스의 테이블에 존재하는 컬럼들을 필드로 가지는 객체이다. (실제 DB의 테이블과 1:1로 매핑되며, 테이블이 가지지 않는 컬럼을 필드로 가져서는 안 된다.) Entity는 데이터베이스 영속성(persistent)의 목적으로 사용되는 객체이며, 때문에 요청(Request)이나 응답(Response) 값을 전달하는 클래스로 사용하는 것은 좋지 않다. 또 많은 서비스 클래스와 비즈니스 로직들이 Entity 클래스를 기준으로 동작하기 때문에 Entity 클래스가 변경되면 여러 클래스에 영향을 줄 수 있다.

 

Entity에서는 setter 메서드의 사용을 지양해야 한다. 이유는 변경되지 않는 인스턴스에 대해서도 setter로 접근이 가능해지기 때문에 객체의 일관성, 안전성을 보장하기 힘들어지기 때문이다. (setter 메서드가 있다는 것은 불변하지 않다는 것이 된다!)

 

따라서 Entity에는 setter 대신 Constructor(생성자) 또는 Builder를 사용하게 되는데, setter 메서드가 아닌 생성자(Constructor)를 이용해서 초기화하는 경우 불변 객체로 활용할 수 있고, 불변 객체로 만들면 데이터를 전달하는 과정에서 데이터가 변조되지 않음을 보장할 수 있다.

 

**DTO(Data Transfer Object)

 

DTO는 계층(Layer) 간 데이터 교환이 이루어질 수 있도록 하는 객체로 JSON serialization과 같은 직렬화에도 사용되는 객체이다. DTO는 원래 DAO(Data Access Object) 패턴에서 유래된 단어로 DAO에서 DB 처리 로직을 숨기고 DTO라는 결괏값을 내보내는 용도로 활용했다. Controller 같은 클라이언트 단과 직접 마주하는 계층에서는 Entity 대신 DTO를 사용해서 데이터를 교환하며, Controller 외에도 여러 레이어 사이에서 DTO를 사용할 수 있지만 주로 View와 Controller 사이에서 데이터를 주고받을 때 활용성이 높다.

 

DTO는 getter, setter 메서드를 포함하며, 이 외의 비즈니스 로직은 포함하지 않는다. (데이터 교환만을 위해 사용하기 때문!)

**setter 메서드를 가지는 경우 가변 객체로 활용할 수 있다.

 

 

** 지극히 개인적인 생각 **

왜 매번 Entity ↔ DTO의 과정이 필요할까라는 의문이 들었었다. 어짜피 데이터를 가져오고, 업데이트 하는것일 텐데 ?

사수께서도 말씀해주셨지만,

만약에 Dto가 없이 Entity만 존재한다고 가정하면 DB와 직접적으로 매핑되어있는 Entity가 변경되면 여러 클래스에 영향을 미치게 될 것이다. 하지만, Dto가 존재한다면 변경사항을 Entity가 아닌 View와 통신하는 Dto에서 처리하고 마지막 단계만 Entity에서 처리되도록 한다면 클래스에 영향이 덜 미치게 되어서 인 것 같다. 

유즈케이스 (Use cases)

애플리케이션 계층으로도 불리며, 어플리케이션 규모의 비즈니스 규칙을 포함한다. 이 레이어의 변경사항은 엔티티에 영향을 미쳐서는 안 되며, 인프라 단의 DB나 UI, 라이브러리와 같은 외부요소에 의해 영향을 받지 않는다는 것을 원칙으로 한다. 즉, 해당 계층의 수정은 응용 프로그램의 동작에 영향을 미친다는 의미이다.

 

인터페이스 어뎁터 (Interface Adapter)

어뎁터 계층은 DB나 Web, UI와 같은 바깥 계층에서 사용하기 편리하도록, 유즈케이스 또는 엔티티 계층에서 데이터를 변환하는 어뎁터의 집합이다. 흔히 MVC, MVVM과 같은 아키텍처를 포함하는 것이 이 영역으로 컨트롤러, 프레젠터, 게이트웨이 등이 속한다.

 

프레임워크 & 드라이버 (Frameworks & Drivers)

인프라 계층이라고도 불리며, 가장 외부에 있는 레이어로 DB, 웹 프레임워크와 같은 세부 정보(Details)를 나타내는 계층이다.

이곳은 보통 글루 코드(Glue code)만 작성하며, 시간이 지남에 따라 구성이 변경될 수 있으므로 엔티티 계층(또는 도메인 계층)에 추상화(abstracted)하여 도메인 계층에 영향을 주지 않고 인터페이스를 수정하고 업데이트할 수 있다.

 

주요 원칙

(사실 더 많지만 이해한 개념만 정리하려고 한다..)

 

Dependency rule (종속성 규칙)

종속성의 흐름을 제어하는 것이 주 목적. 캡슐화를 통해 내부 계층을 외부 계층과 분리시키고 내부는 외부를 모르게 하며 영향을 받지 않도록 종속성의 흐름을 제어할 수 있다.

 

Abstraction principle (추상화 원리)

가장 안쪽에 있는 계층이 제일 추상화된 영역으로 바깥 영역으로 향할수록 내부 계층을 활용하여 세부 사항을 구현한다.

 

SOLID (객체 지향 설계 원칙)

확장가능하며 유지보수 가능한 유연한 소프트웨어 아키텍처를 만들기 위한 5가지의 필수 원칙이다.

 

1. 단일 책임 원칙(SRP) - 클래스(함수와 데이터를 결합한 집합)는 하나의 이유(액터)만으로 수정되어야 하며 하나의 책임/기능/역할을 가져야 한다.
2. 개방-폐쇄 원칙(OCP) - 객체는 확장할 수 있어야 하고, 변경에는 닫혀있어야 한다.
3. 리스코프 치환 원칙(LSP) - 상위 타입의 객체를 하위 타입의 객체로 치환해도 정상 동작해야 한다.
4. 인터페이스 분리 원칙(ISP) - 클라이언트는 자신이 사용하는 함수에만 의존해야 하며, 인터페이스는 더 작게 분리되어야 한다.
5. 의존 역전 원칙(DIP) - 고수준 모듈은 저수준 모듈(세부사항)을 의존해서는 안되며, 추상화에 의존해야 한다.

위의 원칙 중 DIP는 가장 중요한 요소로 Presenter이 경계를 넘어(Crossing Boundaries) Controller로 부터 데이터 흐름을 받는 것을 예시로 들 수 있다.