좋은 아키텍처는 다음을 지원해야 한다.
- 시스템의 유스케이스
- 시스템의 운영
- 시스템의 개발
- 시스템의 배포
📕 유스케이스
시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다.
좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.
📗 운영
시스템의 운영 지원 관점에서 볼 때 아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다.
각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않는다면, 시간이 지나 운영에 필요한 요구사항이 바뀌더라도 스레드, 프로세스, 서비스로 구성된 기술 스펙트럼 사이를 전환하는 일이 훨씬 쉬어질 것이다.
📙 개발
아키텍처는 개발환경을 지원하는 데 있어 핵심적인 역할을 수행한다.
콘웨이(Conway)의 법칙이 작용하는 지점이 바로 여기다.
많은 팀으로 구성된 상황에서 개발을 해야 한다면, 각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보해야 한다.
- 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템 분할하여 개발한다.
콘웨이의 법칙 : 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
📘 배포
좋은 아키텍처는 즉각적인 배포(immediate deployment)를 목표로 한다.
- 시스템이 빌드 된 이후 즉각적으로 배포될 수 있도록 지원한다.
이를 위해서는 시스템을 컴포넌트 단위로 분할하고 격리한다.
- 여기에는 마스터 (메인) 컴포넌트도 포함되는데, 해당 컴포넌트는 시스템 전체를 하나로 묶고, 각 컴포넌트를 올바르게 구동하고 통합하고 관리해야 한다.
📒 선택사항 열어놓기
좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.
📕 계층 결합 분리
아키텍트는 시스템의 의도를 분명하게 알고 있기 때문에 단일 책임 원칙과 공통 폐쇄 원칙을 적용하여, 그 의도의 맥락에 따라서 다른 이유로 변경되는 것들을 분리하고, 동일한 이유로 변경되는 것들을 묶는다.
- 즉, 시스템을 서로 결합 되지 않은 수평적인 계층으로 분리해야한다.
📗 유스케이스 결합 분리
유스케이스는 시스템의 수평적인 계층을 가로지르도록 자른, 수직으로 좁다란 조각이기도 하다.
각 유스케이스는 UI의 일부, 애플리케이션 특화 업무 규칙이 일부, 애플리케이션 독립적 업무 규칙의 일부, 그리고 데이터베이스 기능의 일부를 사용한다.
따라서 우리는 시스템을 수평적 계층으로 분할하면서 동시에 해당 계층을 가로지르는 얇은 수직적인 유스케이스로 시스템을 분할할 수 있다.
결합 분리를 위하여 시스템의 맨 아래 계층까지 수직으로 내려가며 유스케이스들이 각 계층에서 겹치지 않도록 한다.
- 서로 다른 이유로 변경되는 요소들의 결합을 분리한다.
📙 결합 분리 모드
유스케이스를 위해 수행하는 그 작업들(결합 분리)은 운영에도 도움이 된다.
운영 측면에서 이러한 장점을 살리기 위해선 결합을 분리할 때 적절한 모드를 선택해야 한다.
- 컴포넌트를 서비스 단계까지 나눌 수 도 있다.
실제로 서비스에 기반한 아키텍처를 흔히 서비스 지향 아키텍처(SOA)라고 부른다.
📘 개발 독립성
컴포넌트가 분리되면 개발 팀도 분리 가능하다.
📒 배포 독립성
유스케이스와 계층의 결합이 분리되면 배포 측면에서고 고도의 유연성이 생긴다.
- 결합을 제대로 분리하면 운영 중인 시스템에서도 계층과 유스케이스 교체가 가능하다.
📕 중복
중복에는 진짜 중복과 우발적 중복 이 있다.
- 진짜 중복은 개발자라면 중복을 제거하거나 줄여야 한다.
- 우발적 중복은 진짜 중복이 아니다.(서로 다른 속도와 다른 이유로 변경된다면 중복이 아니다.)
모델-뷰-뷰 모델(model-view-viewmodel, MVVM) : 하나의 소프트웨어 아키텍처 패턴으로-마크업 언어 또는 GUI 코드로 구현하는-그래픽 사용자 인터페이스(뷰)의 개발을 비즈니스 로직 또는 백-엔드 로직(모델)로부터 분리시켜서 뷰가 어느 특정한 모델 플랫폼에 종속되지 않도록 해준다.
📗 결합 분리 모드 (다시)
- 소스 수준 분리 모드: 소스 코드 모듈 사이의 의존성을 제어할 수 있다.
- 모든 컴포넌트가 같은 주소 공간에서 실행되고, 서로 통신할 때 간단한 함수 호출을 사용한다. (모노리틱 구조)
- 배포 수준 분리 모드: 배포 가능한 단위(라이브러리, jar 파일, DDL 등)들 사이의 의존성을 제어할 수 있다.
- 독립적으로 배포할 수 있는 단위로 분할되어 있다.
- 서비스 수준 분리 모드: 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고 네트워크 패킷을 통해서만 통신하도록 만들 수 있다.
- 완전히 독립적이다.(서비스, 마이크로 서비스)
컴포넌트가 서비스화될 가능성이 있다면 컴포넌트 결합을 분리하되 서비스가 되기 직전에 멈추는게 좋다.
-> 서비스에 대한 선택권을 열어둔다.
좋은 아키텍처?
- 결합 분리 모드를 선택사항으로 남겨두어 배포 규모에 따라 가장 적합한 모드를 선택해 사용할 수 있게 만들어 준다.
- 모노리틱 구조로 시작해 마이크로서비스 수준까지 성장해도 원래 형태로 돌아갈 수 있어햐 한다.
모노리틱 구조 : 하나의 애플리케이션 안에 모든 비즈니스 로직이 다 들어가 있는 구조
📙 결론
시스템의 결합 분리 모드는 시간이 지나면서 바뀌기 쉬우며, 뛰어난 아키텍트라면 이러한 변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다.
📚 Reference
- Clean Architecture : 소프트웨어 구조와 설계의 원칙
