클린 아키텍처 요약 - 5부. 아키텍처 (1)

15장. 아키텍처란

• 0아키텍트는 프로그래머다. 소프트웨어 아케텍트는 코드와 동떨어지면 안된다.
• 개발, 배포, 운영, 유지보수를 쉽게 만들기 위한 방법은 다음과 같다. 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략이 필요하다

 

개발

• 팀 구조가 다르다면 아키텍처 관련 결정에서도 차이가 난다.
  • 다섯 명 이하로 작다면 잘 정리된 컴포넌트가 없는 모놀리틱 같은 개발을 할 수 있다.
  • 일곱 명 씩으로 구성된 다섯팀이 개발한다면 잘 설계된 컴포넌트 단위로 분리해야한다.

 

배포

• 한번에 쉽게 배포할 수 있도록 설계해야 한다.
• MSA 구조일 때 초기에는 대체로 안정적일 수 있다. 독립적인 인터페이스와 잘 분리된 컴포넌트들로 구성 되어 있기 때문이다. 하지만 배포할 시기가 되면 서비스 별 작동 순서를 결정하는 등의 과정에서 오작동을 유발할 수 있다.

운영

• 아키텍처가 운영에 미치는 영향은 상대적으로 작다.
• 운영은 보통 하드웨어를 더 투입해서 해결할 수 있다. 하드웨어보다 인력 비용이 더 비싸다. 운영을 방해하는 아키텍처가 개발, 배포, 유지보수를 방해하는 아키텍처보다는 비용이 덜 든다.

 

유지보수

• 유지보수는 모든 측면에서 비용이 가장 많이 든다. 가장 큰 비용은 탐사(spelunking)이다.
• 컴포넌트를 분리하고 안정된 인터페이스를 두어 서로 격리한다.

 

선택사항 열어 두기

• 모든 소프트웨어는 주요한 두가지 요소인 정책과 세부사항으로 분해할 수 있다.
• 중요하지 않은 세부사항을 선택할 수 있도록 가능한 오랫동안 열어 두어야 한다
  • 고수준의 정책은 어떤 종류의 DBMS를 사용하는지 신경쓰지 않는다.
  • 고수준의 정책은 웹서버를 통해 데이터를 전달하는 사실을 알아서는 안된다.
  • 고수준의 정책은 외부 세계로의 인터페이스에 독립적이기에 REST를 적용할 필요 없다.
  • 의존성 주입 프레임워크를 적용할 필요가 없다.
• 뛰어난 아키텍트라면 이러한 결정이 내려지지 않은 것처럼 행동한다.

 

.. 사례 중략

 

결론

• 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합도지 않도록 엄격하게 분리한다.
• 세부사항에 대한 결정을 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계한다.

 

16장. 독립성

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

• 유스케이스, 운영, 개발, 배포

 

유스케이스

• 아키텍트의 최우선 관심사는 유스케이스이다.
• 유스케이스는 시스템 구조자체에서 한눈에 드러날 것이다.
  • 이들 행위는 일급요소이다.
  • 시스템 최상위 수준에서 쉽게 알아 볼 수 있다.
  • 개발자가 일일이 찾아 헤매지 않는다.
  • 자신의 기능을 분명하게 나타내는 이름을 가진다.

유스케이스 : actor가 목적을 달성하기 위한 시나리오의 집합

 

운영

• 다양한 운영상 이슈를 해결 할 수 있는 구조로 설계해야 한다.
• 기술 사이의 변환을 쉽게 할 수 있어야 한다.
• 각 컴포넌트를 적절히 격리하고 통신 방식을 특정 형태로 제한하지 말자.

 

개발

• 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 내어야 한다.
• 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

 

배포

• 핵심은 즉각적인 배포이다.
• 시스템 전체를 하나로 묶고, 각 컴포넌트를 통합 관리해야 한다.

 

(선택사항 열어놓기 생략.. '아키텍처-선택사항 열어놓기'와 내용 유사)

계층 결합 분리

• 어플리케이션 업무규칙과 도메인 업무규칙을 독립적으로 변경할 수 있어야한다.
  • 어플리케이션 업무규칙 : 입력값 유효성 검사
  • 도메인 업무규칙 : 이자계산, 재고품 집계
• DB, 쿼리언어, 스키마 등은 기술적인 세부사항이며 업무 규칙이나 UI와는 상관이없다.

 

유스케이스 결합 분리

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

 

결합 분리 모드

• 유스케이스에서 서로 다른 관점이 분리되었다면, 처리량에 대한 유스케이스도 분리되어 있을 가능성이 높다.
• 결과적으로, 유스케이스를 위해 하는 결합 분리 작업은 운영에도 도움이 된다.

 

중복

• 거짓 혹은 우발적 중복과 진짜 중복을 가려내야 한다.
• 거짓 혹은 우발적 중복은 코드를 통합하면 안되고 분리해야 한다.
  • 서로 다른 속도와 다른 이유로 변경 되는 것
  • 두 유스케이스의 화면 구조가 매우 비슷하다고 가정했을 때 코드를 통합하고 싶겠지만, 우발적 중복일 가능성이 크다.
  • 계층구조도 마찬가지이다. DB record를 그대로 UI까지 전달하고 싶을 수 있지만, 이것은 우발적 중복가능성이 크다.

 

결론

변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다.