05 아키텍처 (2)

16장. 독립성

좋은 아키텍처는 다음을 지원해야 한다.

• 시스템의 유스케이스
• 시스템의 운영
• 시스템의 개발
• 시스템의 배포

---

유스케이스

유스케이스는 시스템의 의도이며, 아키텍처는 반드시 유스케이스를 지원해야한다.

아키텍처가 시스템의 행위에 영향을 주지는 않지만, 행위를 명확히 하고 외부에 드러내어 행위를 지원해야 한다.

좋은 아키텍처의 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러난다.

운영

시스템의 운영 지원 관점에서 아키텍처는 더 실질적인 역할을 맡는다.

운영 작업에서 필요로하는 처리량과 응답시간을 보장할 수 있는 형태로 아키텍처를 구조화해야한다.

시스템이 모노리틱 구조로 되어있다면 다중프로세스, 다중 스레드, 마이크로 서비스 등의 형태가 필요할 때 개선하기 어렵다.

각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 유연하게 전환이 가능하다.

개발

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

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

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

이를 위해 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

배포

아키텍처의 목표는 '즉각적인 배포'이다.

꼭 필요한 디렉터리나 파일을 수작업으로 생성하게 하지 않아야하고, 시스템이 빌드된 후에 즉각 배포될 수 있도록 지원해야한다.

역시 시스템을 컴포넌트로 적절하게 분할하고 격리시켜야 한다. 

그리고 마스터 컴포넌트로 시스템 전체를 하나로 묶고, 각 컴포넌트를 올바르게 구동하고 통합하고 관리해야 한다.

선택사항 열어놓기

컴포넌트 구조와 관련된 관심사 모두를 만족시키기란 어렵다.

모든 유스케이스를 알 수 없고, 운영에 따르는 제약사항, 팀 구조, 배포 요구사항도 알지 못한다.

우리가 도달하려는 목표는 뚜렷하지 않으며 시시각각 변한다.

몇몇 아키텍처 원칙을 구현하면 시스템을 제대로 격리된 컴포넌트로 분할할 수 있게 도와주고, 선택사항을 열어 둘 수 있게 된다.

계층 결합 분리

아키텍트는 유스케이스 전부를 알지는 못하지만 시스템의 기본적인 의도는 분명히 알고있다.

따라서 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여, 시스템을 서로 결합되지 않은 수평적인 계층으로 분리해야 한다. ex) UI, 데이터베이스, 애플리케이션에 특화된 업무규칙(필드유효성검사 등), 애플리케이션과 독립된 업무규칙(계좌 이자 계산 등)

유스케이스 결합 분리

각 유스케이스는 UI의 일부, 애플리케이션 특화 업무 규칙의 일부, 애플리케이션 독립 업무 규칙의 일부, 데이터베이스 기능의 일부를 사용한다. ex) 주문추가 유스케이스와 주문삭제 유스케이스

따라서 시스템을 수평적 계층으로 분할하면서 동시에 해당 계층을 가로지르는 얇은 수직적인 유스케이스로도 시스템을 분할할 수 있다.

유스케이스들이 각 계층에서 서로 겹치지않게 분할하면, 새로운 유스케이스를 추가하더라도 기존 유스케이스에 영향을 거의 주지 않는다.

결합 분리 모드

유스케이스를 위해 수행하는 작업들(결합분리)은 운영에 도움이 된다.

UI와 데이터베이스는 업무 규칙과 다른 서버에서 실행될 수 있고, 높은 대역폭을 요구하는 유스케이스는 여러 서버로 복제해서 실행할 수 있다.

분리된 컴포넌트가 서로 다른 서버에서 실행되어야 한다면, 반드시 독립된 서비스가 되어야하고 네트워크를 통해 통신해야 한다. 이러한 컴포넌트를 '서비스' 또는 '마이크로서비스'라고 부른다.

이렇게 때때로 컴포넌트를 서비스 수준까지도 분리해야 한다.

개발 독립성

컴포넌트가 분리된 아키텍처에서는 팀 사이의 간섭이 줄어든다.

기능 팀, 컴포넌트 팀, 계층 팀, 또 다른 형태의 팀들도 시스템 아키텍처가 그 팀 구조를 뒷바침해준다.

배포 독립성

컴포넌트가 분리되면 배포 측면에서도 고도의 유연성이 생긴다.

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

중복

중복에는 두가지 종류가 있다.

진짜 중복은 한 인스턴스가 변경되면, 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용해야 한다.

우발적인 중복은 중복처럼 보이지만, 두 코드가 각자의 경로로 발전하면서 점차 달라진다.

유스케이스의 화면 구조가 비슷하다고 하더라도 우발적인 중복일 가능성이 높다.

이러한 코드를 통합하지 않도록 유의해야하며, 그렇지 않으면 나중에 다시 분리하느라 수고를 감수해야 한다.

우발적인 중복을 통합하는 것보단 계층 간 분리를 유지하는 것이 더 중요하다.

 

결합 분리 모드(다시)

계층과 유스케이스의 결합을 분리하는 방법

• 소스 수준 분리 모드
  - 소스코드 모듈 사이의 의존성을 제어
  - 모든 컴포넌트가 같은 주소 공간에서 실행되고 서로 통신 가능
  - 모노리틱 구조
• 배포 수준 분리 모드
  - jar 파일, DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어
  - 많은 컴포넌트가 여전히 같은 주소 공간에 상주하며, 함수 호출을 통해 통신 가능
  - 프로세스 간 통신, 소켓, 공유 메모리를 통해 통신하는 컴포넌트들도 존재
• 서비스 수준 분리 모드
  - 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고, 네트워크 패킷을 통해서만 통신하도록 만들 수 있음
  -모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 완전히 독립적
  - 서비스 또는 마이크로서비스

프로젝트 초기에는 어떤 모드가 최선인지 알기 어렵다.

단순히 서비스 수준에서의 분리를 기본 정책으로 삼는다면, 비용이 많이 들고 결합이 큰 단위에서 분리된다는 문제가 있다.

따라서 컴포넌트 결합을 분리하되 서비스가 되기 직전에 멈춘고 컴포넌트들을 동일한 주소공간에 남겨둔다면, 서비스에 대한 선택권을 열어 둘 수 있다.

초기에는 소스 코드 분리 수준이었다가 점차 서비스화하는 방향으로 변경해 나갈 수 있다.