클린 아키텍처:소프트웨어 구조와 설계의 원칙(Clean Architecture) - 5부 : 아키텍처 (16장)

[16장] 독립성

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

-시스템의 유스케이스

-시스템의 운영

-시스템의 개발

-시스템의 배포

 

[유스케이스]

시스템의 아키텍처는 시스템의 의도를 지원해야 한다. 아키텍트의 최우선 관심사는 유스케이스이며, 아키텍처에서도 유스케이스가 최우선이다.

아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않는다. 행위와 관련하여 아키텍처가 열어 둘 수 있는 선택사항은 거의 없다. 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.

 

[운영]

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

 

[개발]

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

각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보하여 개발하는 동안 팀들이 서로를 방해하지 않도록 해야 한다. 이러한 아키텍처를 만들려면 잘 격리되어 독립적으로 개발 간으한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

 

[배포]

즉가적인 배포(immediate deployment)

좋은 아키텍처는 꼭 필요한 디렉터리나 파일을 수작업으로 생성하게 내버려 두지 않는다. 좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 한다.

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

 

[선택사항 열어놓기]

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

 

[계층 결합 분리]

아키텍트는 필요한 모든 유스케이스를 지원할 수 있는 시스템 구조를 원하지만, 유스케이스 전부를 알지는 못한다. 하지만 아키텍트는 시스템의 기본적인 의도는 분명히 알고 있다. 따라서 아키텍트는 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여, 그 의도의 맥락에 따라서 다른 이유로 변경되는 것들은 분리하고, 동일한 이유로 변경되는 것들은 묶는다.

뛰어난 아키텍트는 유스케이스에서 UI부분과 업무 규칙 부분을 서로 분리하고자 할 것이다. 업무 규칙은 그 자체가 애플리케이션과 밀접한 관련이 있거나, 혹은 더 범용적일 수도 있다. 서로 다른 두 유형의 규칙은 각자 다른 속도로, 그리고 다른 이유로 변경될 것이다. 따라서 이들 규칙은 서로 분리하고, 독립적으로 변경할 수 있도록 만들어야만 한다.

 

[유스케이스 결합 분리]

각 유스케이스는 UI의 일부, 애플리케이션 특화 업무 규칙의 일부, 애플리케이션 독립적 업무 규칙의 일부, 그리고 데이터베이스 기능의 일부를 사용한다. 따라서 우리는 시스템을 수평적 계층으로 분할하면서 동시에 해당 계층을 가로지르는, 얇은 수직적인 유스케이스로 시스템을 분할할 수 있다. 시스템의 맨 아래 계층까지 수직적으로 내려가며 유스케이스들이 각 계층에서 서로 겹치지 않게 한다.

 

[결합 분리 모드]

유스케이스를 위해 수행하는 결합 분리는 운영에도 도움이 된다. 하지만 운영 측면에서 이점을 살리기 위해선 결합을 분리할 때 적절한 모드를 선택해야 한다. 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고, 일종의 네트워크를 통해 서로 통신해야 한다.

마이크로서비스(micro-service). 서비스 지향 아키텍처(serice-oriented architecture)

좋은 아키텍천느 선택권을 열어 둔다는 사실이다. 결합 분리 모드는 이러한 선택지 중 하나다.

 

[개발 독립성]

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

 

[배포 독립성]

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

 

[중복]

소프트웨어에서 중복은 일반적으로 나쁜 것이다. 코드가 진짜로 중복되었다면, 우리는 전문가로서의 명예를 걸고 중복을 줄이거나 제거해야 한다. 하지만 중복에도 여러 종류가 있다. 그중 하나는 진짜 중복이다. 또 다른 중복은 거짓된 또는 우발적인 중복이다. 중복으로 보이는 두 코드 영역이 각자의 경로로 발전한다면, 즉 서로 다른 속도와 다른 이유로 변경된다면 이 두 코드는 진짜 중복이 아니다.

시간이 지나면서 두 화면은 서로 다른 방향으로 분기하며, 결국에는 매우 다른 모습을 가질 가능성이 높다. 이러한 이유로, 해당 코드를 통합하지 않도록 유의해야 한다. 그렇지 않으면 나중에 코드를 다시 분리하느라 큰 수고를 감수해야 한다.

조심하라. 자동반사적으로 중복을 제거해버리는 잘못을 저지르는 유혹을 떨쳐내라. 중복이 진짜 중복인지 확인하라.

 

[결합 분리 모드]

-소스 수준 분리 모드: 하나의 모듈이 변하더라도 다른 모듈을 변경하거나 재컴파일하지 않도록 만들 수 있다.

-배포 수준 분리 모드: DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어할 수 있다. 다른 모듈을 재빌드하거나 재배포하지 않도록 만들 수 있다.

-서비스 수준 분리 모드: 모든 실행 가능한 단위는 소스와 바이너리 변경에 대해 서로 완전히 독립적이게 된다.(마이크로서비스)

프로젝트 초기 단계는 어떤 모드가 최선인지 알기 어렵다. 사실 프로젝트가 성숙해갈수록 최적인 모드가 달라질 수 있다.

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

 

[결론]

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