16장 - 독립성

좋은 아키텍트는 다음을 지원해야 합니다.

- 시스템의 유스케이스

- 시스템의 운영

- 시스템의 개발

- 시스템의 배포

 

유스케이스

아키텍트는 시스템의 의도를 지원해야 합니다.

예를 들어 시스템이 장바구니 애플리케이션이라면 장바구니와 관련된 유스케이스를 지원해야 합니다.

 

만약 좋은 아키텍처를 갖춘다면 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 것입니다.

이들 행위는 일급 요소이며 시스템의 최상위 수준에서 알아볼 수 있으므로 개발자가 일일이 찾아 헤매지 않아도 됩니다.

 

운영

시스템이 초당 100,000명의 고객을 처리해야 한다면, 아키텍처는 이 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답 시간을 보장해야 합니다.

 

이런 형태를 지원하기 위한 시스템은 다양한 의미를 지닙니다.

- 시스템의 처리 요소를 일련의 작은 서비스로 배열하여 병렬로 실행할 수 있도록 만듦

- 경량의 수많은 스레드가 단일 프로세서에서 같은 주소 공간을 공유하도록 만듦

- 독립된 주소 공간에서 실행되는 소수의 프로세스

- 단일 프로세스에서 실행되는 단순한 모노리틱 프로그램

 

뛰어난 아키텍트라면 모두 열어두어야 하는 선택사항 중의 하나입니다.

만약 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영에 필요한 요구사항이 바뀌더라도 스레드, 프로세스, 서비스로 구성된 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬워질 것입니다.

 

 

개발

콘웨이의 법칙

시스템을 설계하는 조직이라면 어디든 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.

 

많은 팀으로 구성되어 있고 관심사가 다양한 조직에서 시스템을 개발한다면, 각 팀이 독립적으로 행동하기 편한 아키텍처를 확보하여 개발하는 동안 팀들이 서로 방해되지 않도록 해야 합니다.

즉, 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 합니다.

 

배포

좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 합니다.

 

선택사항 열어놓기

좋은 아키텍처는 컴포넌트 구조와 관련된 이 관심사들 사이에서 균형을 맞추고, 각 관심사를 모두 만족시킨다.

말은 쉽지만 현실에서 이런 균형을 잡기가 매우 어렵습니다.

 

요구사항들은 전부 알 수 없으며 알고 있더라도 이 사항들이 반드시 변해갑니다.

따라서 시스템을 격리된 컴포넌트 단위로 분할하며 선택사항을 가능한 많이 가능한 오랫동안 열어두어야 합니다.

 

이를 통해 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있어야 합니다.

 

계층 결합 분리

아키텍트는 모든 유스케이스를 지원할 수 있는 시스템 구조를 원하지만 유스케이스 전부를 알진 못합니다. 하지만 시스템이 장바구니, 주문 처리인지는 확실하게 알고 있습니다.

따라서 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여 다른 이유로 변경되는 것은 분리하고 동일한 이유로 변경되는 것은 묶습니다.

예를 들어 UI와 업무 규칙은 분리되어야 합니다.

비슷하게 데이터베이스, 쿼리, 스키마도 세부사항이며 업무 규칙이나 UI와는 관련이 없습니다.

이들은 다른 속도, 다른 이유로 변경되기 때문에 독립적으로 변경할 수 있어야 합니다.

이런 계층의 예로 UI, 애플리케이션에 특화된 업무, 애플리케이션과는 독립된 업무, 데이터베이스 등을 들 수 있습니다.

 

유스케이스 결합 분리

계층 이외에도 유스케이스도 주문을 추가하는 케이스와 주문을 삭제하는 케이스는 틀림없이 다른 속도, 다른 이유로 변경되기 때문에 분할되어야 합니다.

위의 그림처럼 계층은 수평적으로 분할되고, 각 유스케이스 별로는 수평적으로 분할됩니다.

 

결합 분리 모드

이렇게 결합을 분리하면 운영 관점에 어떤 의미가 있을까요?

만약 서로 다른 관점이 분리되었다면 높은 처리량을 보장해야 하는 유스케이스와 낮은 처리량으로도 충분한 유스케이스는 이미 분리되어 있을 가능성이 높습니다.

높은 대역폭을 요구하는 유스케이스는 여러 서버로 복제하여 실행할 수 있습니다.

이런 이점을 살리기 위해서는 분리된 컴포넌트는 독립된 서비스가 되고, 네트워크를 통해 서로 통신해야 합니다.

흔히 마이크로서비스라고 말하지만 여기서 중요한 건 컴포넌트를 때때로 서비스 수준까지 분리해야 되며 선택지를 열어두는 하나의 예시입니다.

 

개발 독립성

유스케이스의 결합이 분리되면 addOrder 유스케이스에 중점을 둔 팀이 deleteOrder 유스케이스에 중점을 둔 팀에는 개입할 가능성은 거의 없습니다.

 

배포 독립성

유스케이스와 계층의 결합이 분리되면 배포 측면에서도 유연성이 생깁니다.

운영중인 시스템에서도 계층과 유스케이스를 교체할 수 있습니다.

새로운 유스케이스를 추가하는 일은 시스템의 나머지는 그대로 둔 채 새로운 jar파일이나 서비스 몇 개를 추가하는 정도로 단순한 일이 됩니다.

 

중복

중복은 일반적으로 나쁘지만 서로 다른 속도와 이유로 변경된다면 두 코드는 중복이 아닙니다.

SRP의 관점에서 우발적 중복을 잘 관찰하지 않는다면 중복을 제거한 코드를 시간이 지나 다시 분리해야 할 가능성이 있습니다.

 

결합 분리 모드(다시)

계층과 유스케이스는 소스코드, 바이너리, 실행 단위 수준에서도 분리할 수 있습니다.

소스 수준 코드 분리: 소스 코드 모듈 사이의 의존성을 제어해서 하나의 모듈이 변해도 다른 모듈을 변경하거나 재컴파일하지 않도록 만들 수 있습니다.

컴포넌트가 같은 주소 공간에서 실행되고 간단한 함수 호출을 사용합니다.

 

배포 수준 분리 모드: jar파일, DDL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어할 수 있습니다. 컴포넌트가 같은 주소 공간에서 실행되고 간단한 함수 호출을 통해 통신할 수 있습니다. 프로세스간 통신, 소켓, 또는 공유 메모리를 통해 통신할 수 있습니다.

 

서비스 수준 분리 모드: 순전히 네트워크 패킷을 통해서만 통신하도록 만들 수 있습니다. (마이크로 서비스)

 

프로젝트가 성숙해갈수록 최적인 모드가 달라질 수 있습니다.

마이크로서비스가 인기 있어 보이지만 개발 시간,시스템 자원 측면에서도 비용이 많이 듭니다.

은탄환은 없기 때문에 좋은 아키텍처는 시스템이 모노리틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 합니다.

또한 상황이 바뀌었을 때 이 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수 있어야 합니다.