Clean Architecture 스터디[16장] 독립성

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

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

 

유스케이스

• 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다.
• 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.

운영

• 시스템의 운영 지원 관점에서 볼 때 아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다.
• 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영에 필요한 요구사항이 바뀌더라도 스레드, 프로세스, 서비스로 구성된 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬어질 것이다.

 

개발

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

 

콘웨이의 법칙

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

 많은 팀으로 구성되며 관심사가 다양한 조직에서 어떤 시스템을 개발해야 한다면, 각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보하여 개발하는 동안 팀들이 서로를 방해하지 않도록 해야 한다. 이러한 아키텍처를 만들려면 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다. 그래야만 이들 컴포넌트를 독립적으로 작업할 수 있는 팀에 할당할 수 있다.

 

배포

좋은 아키텍처는 수십 개의 작은 설정 스크립트나 속성 파일을 약간씩 수정하는 방식을 사용하지 않는다. 좋은 아키텍처는 꼭 필요한 디렉터리나 파일을 수작업으로 생성하게 내버려 두지 않는다. 좋은 아키텍처는 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야한다.

선택사항 열어놓기

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

 

계층 결합 분리

아키텍트는 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여, 그 의도의 맥락에 따라서 다른 이유로 변경되는 것들을 분리하고, 동일한 이유로 변경되는 것들을 묶는다.

 

유스케이스 결합 분리

유스케이스 또한 서로 다른 이유로 변경될 수 있다.

• 유스케이스는 시스템을 분할하는 매우 자연스러운 방법이다.

유스케이스는 시스템의 수평적인 계층을 가로지르도록 자른, 수직으로 좁다란 조각이기도 하다. 각 유스케이스는 UI의 일부, 애플리케이션 특화 업무 규칙이 일부, 애플리케이션 독립적 업무 규칙의 일부, 그리고 데이터베이스 기능의 일부를 사용한다.

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

결합 분리 모드

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

• 운영 측면에서 이러한 장점을 살리기 위해선 결합을 분리할 때 적절한 모드를 선택해야 한다.
  • ex) 분리된 컴포넌트를 서로 다른 서버에서 실행해야 하는 상황이라면, 이들 컴포넌트가 단일 프로세서의 동일한 주소 공간에 함께 상주하는 형태로 만들어져서는 안 된다.
• 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고, 일종의 네트워크를 통해 서로 통신해야 한다.
• 실제로 서비스에 기반한 아키텍처를 흔히 서비스 지향 아키텍처(serice-oriented-architecture, SOA)라고 부른다.

 

개발 독립성

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

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

 

배포 독립성

배포 측면에서 유연성이 생긴다. 결합이 제대로 분리가 되었다면 시스템에서 계층과 유스케이스를 교체할 수 있다.

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

 

중복

중복은 두가지 종류가 있다.

1. 진짜 중복
   • 중복으로 보이는 두 코드 영역이 한 곳 변경 시 다른 곳도 변경해주어야 하는 경우
   • 하나의 코드로 합치는 것이 관리에 용이하다.
2. 우발적 중복
   • 중복으로 보이는 두 코드 영역이 각자의 경로로 발전하는 경우
   • 시간이 지나면서 두 코드는 서로 다른 방향으로 변경될 가능성이 높다.
   • 우발적 중복은 코드를 통합하지 않도록 유의해야 한다. 그렇지 않으면 나중에 다시 코드를 분리하느라 큰 수고를 감수해야 한다.

 

결합 분리 모드(다시)

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

• 소스 수준 분리 모드
  • 소스 코드 모듈 사이의 의존성 제어할 수 있다.
  • 모든 컴포넌트가 같은 주소 공간에서 실행된다.
  • 통신할 때는 간단함 함수 호출을 사용한다.
  • 컴퓨터 메모리에는 하나의 실행 파일만이 로드된다. (모노리틱 구조)
• 배포 수준 분리 모드
  • 배포 가능한 단위들(jar 파일 / DLL / 공유 라이브러리) 사이의 의존성 제어할 수 있다.
  • 많은 컴포넌트가 여전히 같은 주소 공간에서 실행된다.
  • 통신할 때는 간단함 함수 호출을 사용한다.
  • 어떤 컴폰너트는 동일한 프로세서의 다른 프로세스에 상주하고, 프로세스간 통신/소켓/공유메모리 를 통해 통신할 수 있다
• 서비스 수준 분리 모드
  
  • 순전히 네트워크 패킷을 통해서만 통신한다.
  • 모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 서로 완전히 독립적이게 된다. (마이크로서비스 구조)

 

어떤 모드가 사용하기에 가장 좋을까?

• 현 시점 가장 인기 있어보이는 해결책은 단순히 서비스 수준에서의 분리를 기본 정책으로 삼는 것이다..

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

• 좋은 아키텍처는 모노리틱 구조로 시작해 마이크로서비스 수준까지 성장해도 원래 형태로 돌아갈 수 있어햐 한다.

 

결론

시스템의 결합 분리 모드는 시간이 지나면서 바뀌기 쉬우며, 뛰어난 아키텍트라면 이러한 변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다.