좋은 아키텍처가 지원하는 것
•
시스템의 유스케이스
•
시스템의 운영
•
시스템의 개발
•
시스템의 배포
유스케이스
: 시스템의 아키텍처는 시스템의 의도를 지원해야 한다.
•
만약 시스템이 장바구니 애플리케이션이라면 이 아키텍처는 장바구니와 관련된 유스케이스를 제공해야 한다.
•
아키텍트의 최우선 관심사는 유스케이스이며 아키텍처에서도 유스케이스가 최우선이다. 아키텍처는 반드시 유스케이스를 제공해야한다.
•
좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히하고 외부로 드러내며 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼
수 있도록 만드는 것
운영
: 운영 작업을 지원하는 형태로 아키텍처를 구현해야한다.
•
시스템이 단일체로 작성되어 모놀리딕한 구조를 갖는다면 다중 프로세스, 스레드 또는 마이크로서비스 아키텍처를 구현하고자 할때 개선이 어렵다.
•
그에 비해 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면 운영에 필요한 요구사항이 바뀌어도 능동적인 대처가 가
능해진다.
개발
: 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
•
많은 팀으로 구성되며 관심사가 다양한 조직에서 어떤 시스템을 개발해야 한다면 각 팀이 독립적으로 행동하기 쉬운 아키텍처 구조를 확보하여 개발해야 한다.
배포
: 또한 아키텍처는 배포 용이성을 결정하는데 중요한 역할을 한다.
•
이때 목표는 즉작적인 배포다. 좋은 아키텍처는 수십 개의 작은 설정 스크립트가 속성 파일을 약간씩 수정하는 방식을 사용하지 않는다.
•
좋은 아키텍처라면 시스템이 빌드된 후, 즉각적으로 배포될 수 있도록 지원해야 한다.
선택사항 열어놓기
: 좋은 아키텍처는 컴포넌트 구조와 관련된 이 관심사들 사이에서 균형을 맞추고 각 관심사 모두를 만족시킨다. 말은 쉽다
: 현실에선 이런 균형을 잡기가 어렵다. 그렇기 때문에 유도리 있게, 가능한 선택사항을 많이 가능한 오랫동안 열어두고, 변경에 대처할 수 있게끔해야한다.
계층 결합 분리
: 유스케이스 측면에서 아키텍트는 필요한 모든 유스케이스를 지원할 수 있는 시스템 구조를 원하지만 유스케이스 전부를 알지는 못한다.
: 하지만 아키텍트는 시스템의 기본적인 의도는 분명히 알고 있다. 그 시스템이 어떤 시스템인지 알고 있다는 뜻으로 아키텍트는 SRP와 OCP 원칙을 적용하여 그 의도의 맥락에 따라
서 다른 이유로 변경되는 것들은 분리하고 동일한 이유로 변경되는 것들은 묶는 것이 좋다.
유스케이스 결합 분리
: 서로 다른 이유로 변경되는 것에는 또 무엇이 있을까? 바로 유스케이스 그 자체이다.
: 주문 입력 시스템에서 주문을 추가하는 유스케이스는 주문을 삭제하는 유스케이스와는 틀림없이 다른 속도로 그리고 다른 이유로 변경된다.
: 유스케이스는 시스템을 분할하는 아주 자연스러운 방법이다.
결합 분리 모드
: 이렇게 결합을 분리한다면 두 번째 항목인 운영 관점에서 어떤 변화가 있을까?
: 이렇게 분리된 컴포넌트를 서로 다른 서버에서 실행해야 하는 상황이라면, 이들 컴포넌트가 단일 프로세서의 동일한 주소 공간에 함께 상주하는 형태로 만들어져서는 안 된다.
: 분리된 컴포넌트는 반드시 독립된 서비스가 되어야 하고 일종의 네트워크를 통해 서로 통신해야 한다.
: 많은 아키텍트가 이러한 컴포넌트를 '서비스(Service)' 또는 '마이크로서비스(Microservice)라고 하는데, 그 구분 기준은 모호한 면이 있다.
: 실제로 서비스에 기반한 아키텍처를 흔히들 서비스 지향 아키텍처(Service-oriented architecture SOA)라고 부른다.
: 핵심은 컴포넌트를 종종 서비스 수준까지도 분리해야 한다는 것이다.
배포 독립성
: 유스케이스와 계층의 결합이 분리되면 배포 측면에서도 고도의 유연성이 생긴다. 즉 새로운 유스케이스를 추가하는 일은 서비스 몇 개를 추가하는 정도로 단순한 일이 된다.
