[Clean Architecture 정리] 16장. 독립성

16장. 독립성

 

좋은 아키텍처가 지원해야하는 것

1. 유스케이스

아키텍처는 시스템의 유스케이스(의도)를 지원해야 한다.

아키텍처는 시스템의 행위를 명확하게 하고 외부로 드러내며 아키텍처 수준에서 시스템의 의도를 파악할 수 있도록 만들어야 한다.

 

 

2. 운영

운영 관점에서 아키텍처는 더 실질적인 역할을 맡는데, 각 유스케이스에 맞는 처리량과 응답 시간이다.

특정 시스템에서 비기능적인 요구사항이 있다면, 반드시 이러한 운영작업을 처리할 수 있는 형태로 아키텍처를 구조화해야 한다.

 

 

3. 개발

아키텍처는 개발환경과 관련해 핵심적인 역할을 맡으며, 콘웨이 법칙을 적용된다.

각 팀이 독립적으로 개발할 수 있는 형태로 아키텍처를 구성하고, 서로를 방해하지 않도록 해야 한다.

시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
- 콘웨이(Conway) 법칙 -

 

 

4.  배포

아키텍처는 배포 용이성을 결정하는데 중요한 역할을 수행하며, 목표는 '즉각적인 배포(immediate deployment)'이다

 

 

선택 사항 열어두기

좋은 아키텍처는 아키텍처가 지원해야하는 것들 사이에 균형을 맞추고 이들을 모두 만족시켜야 한다.

하지만 현실에선 구체적인 유스케이스부터 제약사항, 배포 요구사항 등 구체적인 내용을 알 수 없으며, 이는 시스템이 성장할수록 변하게 된다.

 

이러한 모호함과 변경 속에서도  아키텍처 원칙은 낮은 비용으로 앞의 관심사(지원해야하는 것)들 사이의 균형을 맞출 수 있도록 한다.

아키텍처 원칙은 시스템을 독립적인 컴포넌트로 분할하고, 선택사항을 최대한 늦추어 가능한 오랫동안 열어둘 수 있다.

 

 

계층 결합 분리

개발을 할 때, 유스케이스 전부를 알 수는 없지만 시스템의 기본적인 의도는 알 수 있다.

따라서, '단일 책임 원칙'과 '공통 폐쇄 원칙'을 적용해 의도의 '맥락'에 맞게 다른 이유로 변경되는 것들을 분리할 수 있다. (UI, 업무 규칙, 데이터베이스 등)

이 원칙을 적용하면 시스템은 결합되지 않는 수평적인 계층으로 분리된다.

 

 

유스케이스 결합 분리

서로 다른 이유로 분리되는 것으로 유스케이스 자체가 있다.

유스케이스로 분리하면 시스템은 앞에서 설명한 의도의 맥락에 따라 구분한 수평적인 계층을 수직방향으로 가로지르는 형태로 시스템을 분리할 수 있다.

 

시스템을 수평적인 계층과 유스케이스에 따라 수직적으로 계층을 나눔으로써, 서로 다른 이유로 변경되는 요소들의 결합을 분리하고 기존 요소에 영향을 주지않은 채 새로운 유스케이스를 추가할 수 있다.

또한, 유스케이스를 뒷받침하는 UI와 데이터베이스를 묶고 각 유스케이스가 다른 관점(aspect)에서 사용하게 되면, 새로운 유스케이스가 기존의 유스케이스에 영향을 주는 일은 거의 발생하지 않는다.(AOP, Aspect Oriented Programming)

 

 

개발 독립성

컴포넌트가 완전 분리되면 각 개발 팀 간의 간섭을 줄어든다. 계층과 유스케이스의 결합이 분리되면, 한 시스템의 아키텍처는 각 팀의 구조를 뒷받침해준다.

 

 

배포 독립성

유스케이스와 계층의 결합이 분리되면, 운영중인 시스템에서도 계층과 유스케이스를 동작에 영향을 미치지 않는 채로 교체할 수 있다.

 

 

중복

개발자는 기본적으로 중복을 피하려고 하는 경향이 있다. 하지만, 모든 중복이 하나로 합쳐져야하는 것은 아니다. 중복에는 '진짜 중복'과 '우발적 중복'이 존재한다.

 

'진짜 중복'은 말 그대로 동일한 코드, 인스턴스가 중복되는 형태로 제거되거나 하나로 합쳐져야하는 요소이다.

'우발적 중복'은 초기에는 중복된 코드였으나, 프로젝트가 성장함에 따라 점점 다른 시점, 다른 속도로 변경되는 요소이다. 이러한 우발적 중복을 합칠 경우에는 나중에 분리하는데 더 많은 비용을 소모하게 될 것이다.

 

중복이 진짜 중복인지 우발적 중복인지 구분하고 하나로 결합한 것인지 분리할 것인지 결정해야 한다.

 

 

결합 분리 모드

운영 관점에서 봤을 때, 유스케이스에서 서로 다른 관점(aspect)로 분리되었을 때, 각 유스케이스에 맞게 처리량과 응답시간 또한 분리되었을 가능성이 높다. 또한, 수평적인 계층으로 분리함으로써, UI, 업무 규칙, 데이터베이스는 각각의 서버에서 운영될 수 있다.

특히, 운영 관점에서는 적절한 *결합 분리 모드를 사용해 시스템을 분리해야 한다.

 

 

1) 소스 수준 분리 모드

소스 코드 모듈 사이의 의존성을 제어할 수 있으며, 한 모듈의 변경이 다른 모듈을 변경하고나 재컴파일하도록 만들지 않는다.

모든 컴포넌트가 같은 주소 공간에서 실행되며, 통신은 간단한 함수 호출을 통해 이루어지므로 비용이 낮다.

흔히 모노리틱(monolithic) 구조라 한다.

 

 

2) 배포 수준 분리 모드

배포 가능한 단위들 사이의 의존성을 제어할 수 있으며, 한 모듈의 변경이 다른 모듈의 재컴파일/재빌드를 유발시키지 않는다.

많은 컴포넌트가 같은 주소 공간에서 실행되며, 어떤 컴포넌트는 다른 프로세스에서 실행될 수 있다. 통신은 간단한 함수 호출 또는 프로세스 간 통신을 통해 이루어진다.

 

 

3) 서비스 수준 분리 모드

의존하는 수준을 데이터 구조 단위까지 낮출 수 있으며, 네트워크를 통해 통신하게 된다.

모든 실행 가능한 단위는 소스와 바이너리의 변경에 대해 완전 독립적이게 된다.

 

어떤 모드가 적절한지에 대해서는 프로젝트에 성숙도 또는 요구사항에 따라 달라질 수 있다.

좋은 아키텍처는 결합 분리 모드를 선택사항으로 남겨두고, 배포 규모에 따라 적합한 모드를 선택할 수 있게 만들어 둔다.

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24