[항해] 2주차, 클린 아키텍처

항해 2주차에는 다양한 아키텍처 중에 클린 & 레이어드 아키텍처 패턴으로 특강 예약 서비스 서버를 구축하는게 발제였다.

레이어드 아키텍처의 한계점과 클린 아키텍처로 상호 보완해서 패키지를 구성한 내용에 대해 정리해보려고 한다.

목차
- 레이어드 아키텍처
- 레이어드 아키텍처의 한계와 개선 방향
- 클린 아키텍처 개념 적용
- 파사드 패턴을 사용한 설계
- 클린 & 레이어드를 적용한 패키지 구조
- 결론

레이어드 아키텍처

아키텍처 설계에서 레이어 중심(interfaces, applicaiont, domain, infrastructure)으로 구분을 하였다.

레이어를 기준으로 구분을 해서 설계하였을 때의 구조적 이점으로는 명확한 책임 분리가 가능해지고, 도메인 재사용성이 증가하고 테스트가 용이해진다.

• 명확한 책임 분리
  • 레이어 각각의 역할과 책임을 분리하여 서로 독립적으로 동작한다.
    • interfaces : 프레젠테이션 및 API 요청 / 응답 처리
    • application : 애플리케이션 로직 (유즈케이스) 처리
    • domain : 핵심 비즈니스 로직과 엔티티 관리
    • infrastructure : 데이터베이스, 외부 API 등 세부 사항 관리
    • common : 공통적으로 사용되는 예외 처리, 커스텀 응답 포맷 정의 
• 재사용성과 확장성
  • 각 도메인 user, lecture, registration이 독립적인 구조를 가지고 있어서 개별적으로 확장하거나, 재사용이 가능하다.
    새로운 기능을 추가하면 한 도메인에만 변경이 집중되어 다른 도메인에 영향을 주지 않게 된다.(OCP, 개방 폐쇄의 원칙)
• 테스트 용이성
  • 계층 별로 테스트가 가능하기 때문에 단위 테스트와 통합 테스트가 수월해진다.

 

레이어드 아키텍처의 한계와 개선 방향

레이어드 구조적 관점으로만 보면 하위 계층에 대한 의존이 생기므로 내부가 변경되면 그 영향이 외부로 점차 전파되어
애플리케이션 전체를 변경해야 하는 단점이 생긴다.

 

클린 아키텍처 개념 적용

클린 아키텍처의 특징을 추가하여 레이어드 구조는 유지하되, 중심을 비즈니스 로직(도메인 계층)으로 설정한다.

(클린 · 레이어드 아키텍처 장점을 결합)
도메인은 최우선으로 두고 나머지 계층은 이를 지원하는 형태로 설계하는 것이다.

• 클린 아키텍처의 장점
  • 의존성 방향은 외부에서 내부로 흐른다.
  • 도메인 계층은 외부 구현 세부 사항에 의존하지 않고 오직 추상화에만 의존한다.
  • 비즈니스 로직(도메인 계층)이 가장 안쪽에 위치하여 변경으로부터 보호한다.
• KEY POINT
  
  • 도메인이 중심이 되는 설계가 되려면 도메인이 '왕'이 되어야 한다. 이를 제외한 나머지 계층은 도메인에 서빙하는 개념이다.
    이 말은 도메인은 구현체에 의존하지 않고, 오직 추상화에만 의존하게 설계하여 추상화된 인터페이스만 호출하여 로직을
    수행한다. (비즈니스 로직이 어떻게 처리되든지 관심 없음.)
  • 현재 구조에서 보면 repository(추상화), repositoryImpl(구현체)로 분리시킨 것을 확인할 수 있는데 이렇게 분리한 이유는
    도메인 계층이 하위 구현체에 직접 의존하지 않도록 하기 위해서다.
      

의존성 역전 전 vs 의존성 역전 후

• 예시 )
  • 의존성 역전 전
    controller -> service -> ORM repository
    : 직접적인 구현체 의존으로 변경의 전파 가능성이 높다.
    
    
  •  의존성 역전 후
    controller -> service -> repository -> repositoryImpl -> ORM repository
    : 추상화를 통해 구현체와 분리, 외부 구현변경이 도메인 계층에 영향을 주지 않는다.
    
    

• 이렇게 함으로써 구현체의 변경이 상위 계층(도메인)에 영향을 미치지 않도록 하고, 하위 추상화에만 의존하도록 구조를 단순화한다.
  또한 구현체는 추상화에 의존하게 되어 의존성 역전 원칙(DIP)을 지키고, 외부 구현체의 변경으로부터 도메인 계층을 보호할 수 있다.

파사드 패턴을 사용한 설계

파사드를 사용하여 도메인 별로 분리된 서비스 로직을 한 곳에 모아 각 기능들이 어우려져서 동작하게 하였다.

컨트롤러에서는 파사드 인터페이스만 호출하면 복잡한 서브 시스템의 동작을 이해할 필요가 없어진다.

 

클린 & 레이어드를 적용한 패키지 구조

 

결론

클린 · 레이어드 아키텍처를 결합해서 설계하면 비즈니스 중심 설계를 구현하면서 기존 레이어드 아키텍처의 친숙함과 장점을 유지할 수 있다. 추상화를 통해서 의존성을 역전 시킴으로써 코드의 변경이 도메인에 직접적인 영향을 끼치지 않도록 한다. 또한 파사드 패턴을 통해 복잡성을 관리하였다.

현업에서는 주로 레이어드 아키텍처 방식을 사용하는데 Repository를 DIP 하여 DB 레이어에 직접 접근하지 못하도록 하는 부분에서 배울 점이 많은 시간이였다. 그리고 추후에 DB 변경이나 다른 외부 라이브러리로의 전환 시 시스템 내부적인 영향을 최소화 할 수 있는 이점이 있을 것 같다.