[16장] 독립성

유스케이스

• 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다. 만약 시스템이 장바구니 애플리케이션이라면, 이 아키텍처는 장바구니와 관련된 유스케이스를 지원해야 한다.
• 하지만 앞서 논의한 바와 같이 아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않는다

• 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다
• 장바구니 애플리케이션이 좋은 아키텍처를 갖춘다면, 이 애플리케이션은 장바구니 애플리케이션처럼 보일 것이다
• 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 것이다. 이들 행위는 일급 요소(first-class element)이며 시스템의 최상위 수준에서 알아볼 수 있으므로 개발자가 일일이 찾아 헤매지 않아도 된다.
• 이들 요소는 클래스이거나 함수 또는 모듈로서 아키텍처 내에서 핵심적인 자리를 차지할 뿐만 아니라, 자신의 기능을 분명하게 설명하는 이름을 가질 것이다. ⇒ 21장 “ 소리치는 아키텍처” 참고

운영

• 시스템의 운영 지원 관점에서 볼 때 아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다.
• 시스템이 초당 100,000명의 고객을 처리해야 한다면, 아키텍처는 이 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답시간을 보장해야 한다.
• 만약 시스템에서 수 밀리초 안에 3차원의 빅데이터 테이블에 질의해야 한다면, 반드시 이러한 운영 작업을 허용할 수 있는 형태로 아키텍처를 구조화해야 한다

• 이상하게 보일 수 있지만, 이러한 결정은 뛰어난 아키텍트라면 열어 두어야 하는 선택사항 중의 하나이다. 만약 시스템이 단일체로 작성되어 모놀리틱 구조를 갖는다면, 다중 프로세스, 다중 스레드, 또는 마이크로 서비스 형태가 필요해질 때 개선하기가 어렵다.
• 그에 비해 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영에 필요한 요구사항이 바뀌더라도 스레드, 프로세스, 서비스로 구성된 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬워질 것이다.

개발

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

• 아키텍처는 개발환경을 지원하는 데 있어 핵심적인 역할을 수행한다.

• 시스템 아키텍처는 개발팀(들)이 시스템을 쉽게 개발할 수 있도록 뒷받침 해야만 한다.

• 각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보하여 개발하는 동안 팀들이 서로를 방해하지 않도록 해야 한다.

배포

• 아키텍처는 배포 용이성을 결정하는 데 중요한 역할을 한다. 이 때 목표는 ‘즉각적인 배포’다

• 좋은 아키텍처는 수십 개의 작은 설정 스크립트나 속성 파일을 약간씩 수정하는 방식을 사용하지 않는다.

• 좋은 아키텍처는 꼭 필요한 디렉터리나 파일을 수작업으로 생성하게 내버려 두지 않는다.

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

• 이러한 아키텍처를 만들려면 시스템을 컴포넌트 단위로 적절하게 분할하고 격리 시켜야 한다.
• 여기에는 마스터 컴포넌트(or 메인 컴포넌트)도 포함되는데 마스터 컴포넌트는 시스템 전체를 하나로 묶고, 각 컴포넌트를 올바르게 구동하고 통합하고 관리해야 한다.

선택사항 열어놓기

• 모든 유스케이스를 알 수는 없으며

• 운영 하는데 따르는 제약사항

• 팀 구조

• 배포 요구사항도 알지 못하기 때문이다.

• 그러나 이런 변화 속에서도 사라지지 않는 것이 있다. 몇몇 아키텍처 원칙은 구현하는 비용이 비교적 비싸지 않으며, 관심사들 사이에서 균형을 잡는데 도움이 된다.

• 이들 원칙은 시스템을 제대로 격리된 컴포넌트 단위로 분할할 때 도움이 되며, 이를 통해 선택사항을 가능한 한 많이, 그리고 가능한 한 오랫동안 열어 둘 수 있게 해준다.

• 좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.

**결합 분리** (중요)

계층 결합 분리

• 아키텍트는 필요한 모든 유스케이스를 지원할 수 있는 시스템 구조를 원하지만, 유스케이스 전부를 알지는 못한다. 하지만 아키텍트는 시스템의 기본적인 의도는 분명히 알고 있다. 그 시스템이 장바구니 시스템인지, 자재 명세서 시스템인지, 또는 주문 처리 시스템인지 안다는 뜻이다.

• 시스템을 서로 결합되지 않은 수평적인 계층으로 분리하는 방법의 예 : UI, 애플리케이션에 특화된 업무 규칙, 애플리케이션과는 독립적인 업무 규칙, 데이터베이스 등

유스케이스 결합 분리

• 서로 다른 이유로 변경되는 것에는 또 유스케이스 자체가 있다.

• 주문 입력 시스템에서 주문을 추가하는 유스케이스는 주문을 삭제하는 유스케이스와는 틀림없이 다른 속도로, 그리고 다른 이유로 변경된다. 유스케이스는 시스템을 분할하는 매우 자연스러운 방법이다.

• 이와 동시에 유스케이스는 시스템의 수평적인 계층을 가로지르도록 자른, 수직으로 좁다란 조각이기도 하다.
• 각 유스케이스는 UI의 일부, 애플리케이션 특화 업무 규칙의 일부, 애플리케이션 독립적 업무 규칙의 일부, 그리고 데이터베이스 기능의 일부를 사용한다.
• 따라서 우리는 시스템을 수평적 계층으로 분할하며 동시에 해당 계층을 가로지르는 얇은 수직적인 유스케이스로 시스템을 분할할 수 있다.

• 여기에서 패턴을 볼 수 있다. 시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가할 수 있게 된다. 또한 유스케이스를 뒷받침하는 UI와 데이터베이스를 서로 묶어서 각 유스케이스가 UI와 데이터베이스의 서로 다른 관점(aspect)을 사용하게 되면 새로운 유스케이스를 추가하더라도 기존 유스케이스에 영향을 주는 일은 거의 없을 것이다.

결합 분리 모드

• 위와 같이 결합을 분리했을 때 운영 관점에서의 의미
• 유스케이스에서 서로 다른 관점(aspect)이 분리되었다면 높은 처리량을 보장해야 하는 유스케이스와 낮은 처리량으로도 충분한 유스케이스는 이미 분리되어 있을 가능성이 높다.
• UI와 데이터베이스가 업무 규칙과 분리되어 있다면 UI와 데이터베이스는 업무 규칙과는 다른 서버에서 실행될 수 있다
• 높은 대역폭을 요구하는 유스케이스는 여러 서버로 복제하여 실행할 수 있다.
• 하지만 운영 측면에서 이점을 살리기 위해서는 결합을 분리할 때 적절한 모드를 선택해야 한다.
• 예를 들어 분리된 컴포넌트를 서로 다른 서버에서 실행해야 하는 상황이라면, 이들 컴포넌트가 단일 프로세서의 동일한 주소 공간에 함께 상주하는 형태로 만들어져서는 안 된다.
• 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고, 일종의 네트워크를 통해 서로 통신해야 한다. 많은 아키텍트가 이러한 컴포넌트를 서비스 또는 마이크로서비스 라고 함

• 기억해야 할 점은 좋은 아키텍처는 선택권을 열어 둔다는 사실이다. 결합분리 모드는 이러한 선택지 중 하나다.

• 계층과 유스케이스의 결합을 분리하는 방법은 다양하다.

1. 소스 수준 분리 모드

• 소스 코드 모듈 사이의 의존성을 제어할 수 있다. 이를 통해 하나의 모듈이 변하더라도 다른 모듈을 변경하거나 재컴파일하지 않도록 만들 수 있다.

• 이 모드에서는 모든 컴포넌트가 같은 주소 공간에서 실행되고, 서로 통신할 때는 간단한 함수 호출을 사용한다. 컴퓨터 메모리에는 하나의 실행파일만이 로드됨. 이러한 구조를 흔히 모노리틱 구조라고 부름

2. 배포 수준 분리 모드

• jar 파일, DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어할 수 있다. 이를 통해 한 모듈의 소스 코드가 변하더라도 다른 모듈을 재빌드 하거나 재배포 하지 않도록 만들 수 있다.

• 많은 컴포넌트가 여전히 같은 주소 공간에 상주하며, 단순한 함수 호출을 통해 통신할 수 있다. 어떤 컴포넌트는 동일한 프로세서의 다른 프로세스에 상주하고, 프로세스 간 통신, 소켓, 또는 공유 메모리를 통해 통신할 수 있다.

• 이 모드의 중요한 특징은 결합이 분리된 컴포넌트가 jar 파일, Gem 파일, DLL과 같이 독립적으로 배포할 수 있는 단위로 분할되어 있다는 점이다.

3. 서비스 수준 분리 모드

• 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고 순전히 네트워크 패킷을 통해서만 통신하도록 만들 수 있다. 이를 통해 모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 서로 완전히 독립적이게 된다 (예: 서비스 or 마이크로서비스)

결합 분리 모드 선택 방법

• 어떤 모드가 사용하기에 가장 좋은가?

• 프로젝트 초기 단계는 어떤 모드가 최선인지 알기 어렵다는 게 답이다. 사실 프로젝트가 성숙해갈수록 최적인 모드가 달라질 수 있다.
• 예를 들어 당장에는 시스템을 단일 서버로도 안정되게 실행할 수 있더라도, 시스템이 성장하면서 결국에는 별도 서버에서 실행해야만 하는 컴포넌트가 생길 거라고 충분히 예상할 수 있다.
• 시스템이 한 서버에서 실행되는 동안은 결합을 소스 수준에서 분리하는 것만으로도 충분하다. 하지만 나중에는 배포 가능한 단위, 심지어는 서비스 수준까지 분리해야 할 수 있다.

• 좋은 아키텍처는 시스템이 모놀리틱 구조로 태어나서 단일 파일로 배포되더라도 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야 한다. 또한 좋은 아키텍처라면 나중에 상황이 바뀌었을 때 이 진행 방향을 거꾸로 돌려 원래 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다.

• 좋은 아키텍처는 이러한 변경으로부터 소스 코드 대부분을 보호한다. 좋은 아키텍처는 결합 분리 모드를 선택 사항으로 남겨두어서 배포 규모에 따라 가장 적합한 모드를 선택해 사용할 수 있게 만들어 준다.

개발 독립성(결합 분리를 함으로써 생기는 이점)

• 컴포넌트가 완전히 분리되면 팀 사이의 간섭은 줄어든다.

• 업무 규칙이 UI를 알지 못하면 UI에 중점을 둔 팀은 업무 규칙에 중점을 둔 팀에 그다지 영향을 줄 수 없다.

• 기능 팀, 컴포넌트 팀, 계층 팀 혹은 또 다른 형태의 팀이라도 계층과 유스케이스의 결합이 분리되는 한 시스템의 아키텍처는 그 팀 구조를 뒷받침해 줄 것이다.

배포 독립성(결합 분리를 함으로써 생기는 이점)

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

• 실제로 결합을 제대로 분리했다면 운영 중인 시스템에서도 계층과 유스케이스를 교체(hot-swap)할 수 있다

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

중복

• 중복 중에는 거짓된 또는 우발적인 중복이 있다. 중복으로 보이는 두 코드 영역이 각자의 경로로 발전한다면, 즉 서로 다른 속도와 다른 이유로 변경된다면 이 두 코드는 진짜 중복이 아니다.
• 예를 들어 두 유스케이스의 화면 구조가 매우 비슷하다고 가정해볼때, 아키텍트는 이 구조에 사용할 코드를 통합하고 싶은 유혹을 강하게 느낄 것이다. 하지만 이 상황은 우발적 중복일 가능성이 높다. 시간이 지나면서 두 화면은 서로 다른 방향으로 분기하며, 결국에는 매우 다른 모습을 가질 가능성이 높다.