Clean Architecture (클린 아키텍처) - 34장. 빠져 있는 장 The Missing Chapter (마지막 장)

■ 34장 빠져 있는 장 The Missing Chapter

** 이번 장은 저자가 아닌 다른 사람이 적은 글이다. (By Simon Brown)

​

악마는 항상 디테일(세부사항)에 있는 법이다. 클린 아키텍처가 물론 도움이 되겠지만 마지막 고비에 걸려 넘어지지 않도록 설계나 코드 조직화와 관련된 몇 가지 추가적인 접근법을 살펴본다. 이 장의 내용은 책의 저자(Robert C. Martin)와 일부 다른 견해도 포함된다.

​

요약하면, 가능한 한 선택사항을 열어두되 실용주의적으로 행하고, 팀의 규모, 기술 수준, 해결책의 복잡성을 일정과 예산이라는 제약과 동시에 고려하라는 것. 또 선택된 아키텍처 스타일을 강제하는 데 컴파일러의 도움을 받을 수 있을지 고민하며, 데이터 모델과 같은 다른 영역에 결합되지 않도록 주의하라는 것이 되겠다.

​

1. 계층 기반 패키지 Package by layer

​

가장 단순한 형태의 설계 방식으로 쉽게 말해 아래 그림처럼 패키지를 웹, 업무 로직, 데이터 계층으로 분리하는 것이다. 이는 작게 시작하기에는 적합하지만 소프트웨어가 커지고 복잡해지면 이 세 개의 층만으로는 부족함을 느끼게 된다.

 

 

2. 기능 기반 패키지 Package by feature

​

계층으로 분리했던 웹, 로직, 데이터를 기능 단위로 분리하는 것이다. 계층 기반 패키지에 비해서 패키지를 보고서 어떤 기능을 하는 것인지 알 수 있다.

 

 

3. 포트와 어댑터 Ports and Adapters

​

세 번째 방법은 업무/도메인 같은 내부 영역을 프레임워크, DB 같은 외부 세계와 분리하는 것이다. 외부가 내부에 의존하는 방향이어야 한다. 아래 그림에서 com.mycompany.myapp.domain 패키지가 내부이며 의존성이 이곳으로 흐르는 것을 볼 수 있다.

 

 

4. 컴포넌트 기반 패키지 Package by Component

​

코드를 조직화하는 방법에 대해 기고자는 저자와 다른 견해를 가지고 있으며 이것을 컴포넌트 기반 패키지라고 명명하였다.

​

※ 계층형 아키텍처의 문제점

Controller가 Service에 의존하려면 Service는 public이어야 하고 마찬가지로 Repository도 public 이어야 한다. 따라서 Controller에서는 Service를 거치지 않고 바로 Repository에 접근하는 것이 가능하다. 이것이 허용되므로 보통 이런 경우를 완화된 계층형 아키텍처라고 부른다. (물론 CORS 패턴과 같이 의도하는 경우도 있다고 함. CORS 패턴은 다음 참조. https://docs.microsoft.com/ko-kr/azure/architecture/patterns/cqrs )

 

 

이렇게 구현하면 동작은 하겠지만 아키텍처 원칙을 지키지 않은 것으로 개발자를 신뢰하는 것과는 별개로 강제성을 부여하는 것이 옳다. 이번 장의 저자(기고자)는 이것을 컴파일러 차원에서 강제화해야 한다고 말한다.

​

컴포넌트 기반 패키지는 아래 그림과 같은 형태인데, 업무로직과 데이터 관련 코드를 하나로 묶는다.

 

 

앞서 언급한 public 얘기로 돌아가면, public을 과용할 경우 아래 그림처럼 위에서 설명한 4가지 아키텍처가 사실상 동일한 형태가 된다.

 

 

여기서 public이면 안 되는 것들을 흐리게 표시한 것이 아래 그림이다.

 

 

이것들 중 4번째 그림인 컴포넌트 기반 패키지에서 보면, 외부에서 OrdersRepository에 접근할 수 있는 방법이 아예 차단된다. 따라서 컴파일러의 도움을 받아서 이러한 아키텍처를 강제화 할 수 있는 것이다. (물론 이는 모노리틱 개발을 전제로 하는 설명이다)

​

​

<끝> 부록 A 아키텍처 고고학 Architecture Archaeology 은 생략함