Post

독립성

16. 독립성

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

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

유스케이스

시스템의 아키텍처는 시스템의 의도를 지원해야 한다.

아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않는다.

행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것

운영

운영 작업을 허용할 수 있는 형태로 아키텍처를 구조화해야 한다

뛰어난 아키텍트라면 열어두여야 하는 선택사항(모노리틱 or 마이크로서비스)

개발

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

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

배포

목표는 즉각적인 배포(immediate deployment)

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

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

선택사항 열어놓기

목표는 뚜렷하지 않고 시시각각 변하기 때문에 관심사를 모두 만족시키기는 현실적으로 어렵다

몇몇 아키텍처 원칙은 구현하는 비용이 비교적 비싸지 않으며, 관심사들 사이에서 균형을 잡는 데 도움이 된다.

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

계층 결합 분리

세부사항은 시스템의 나머지 부분으로부터 분리하여 독립적으로 변경할 수 있도록 해야 한다.

유스케이서 결합 분리

시스템의 맨 아래 계층까지 수직으로 내려가며 유스케이스들이 각 계층에서 서로 겹치지 않게 한다.

시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가할 수 있게 된다.

결합 분리 모드

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

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

유스케이스를 위해 수행하는 작업들은 운영에도 도움이 된다.

서비스에 기반한 아키텍처: SOA(service-oriented architecture)

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

개발 독립성

계층과 유스케이스의 결합이 분리되는 한 시스템의 아키텍처는 그 팀 구조를 뒷받침

배포 독립성

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

hot-swap도 가능

중복

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

우발적 중복: 서로 다른 속도와 다른 이유로 변경된다면 이 코드는 진짜 중복이 아니다.

자동반사적으로 중복을 제거해버리는 잘못을 저지르는 유혹을 떨쳐내라(진짜 중복인지 확인!)

결합 분리 모드(다시)

  • 소스 수준 분리 모드: 소스 코드 모듈 사이의 의존성을 제어 가능

    모든 컴포넌트가 같은 주소 공간에서 실행되고, 간단한 함수 호출을 사용하여 통신

    모노리틱 구조

  • 배포 수준 분리 모드: jar 파일, DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어할 수 있다.

    한 모듈의 소스 코드가 변하더라고 다른 모듈을 재빌드하거나 재배포하지 않도록 만들 수 있다.

  • 서비스 수준 분리 모드: 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고, 순전히 네트워크 패킷을 통해서만 통신하도록 만들 수 있다.

    모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 서로 완전히 독립적(ex. 마이크로서비스)

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

좋은 아키텍처라면 나중에 상황이 바뀌었을 때 이 진행 방향을 거꾸로 돌려 원래의 형태인 모노리틱 구조로 되돌릴 수도 있어야 한다.

참조

  1. 클린 아키텍처(Clean Architecture)
This post is licensed under CC BY 4.0 by the author.