좋은 아키텍처에는 다음을 지원해야 한다.
시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다.
아키텍처는 반드시 유스케이스를 지원해야 한다.
좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.
아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다.
만약 시스템이 단일체(monolith)로 작성되어 모노리틱 구조로 갖는다면, 다중 프로세스, 다중 스레드, 또는 마이크로서비스 형태가 필요해질 때 개선하기가 어렵다.
콘웨이의 법칙
아키텍처는 배포 용이성을 결정하는 데 중요한 역할을 한다.
이때 목표 : 즉각적인 배포
좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야 한다.
좋은 아키텍처는 컴포넌트 구조와 관련된 이 관심사들 사이에서 균형을 맞추고, 각 관심사 모두를 만족시킨다.
현실에서는 이러한 균형을 잡기가 매우 어렵다. 대부분의 경우 우리는 모든 유스케이스를 알 수는 없으며, 운영하는 데 따르는 제약사항, 팀 구조, 배포 요구사항도 알지 못하기 때문이다.
몇몇 아키텍처 원칙은 구현하는 비용이 비교적 비싸지 않으며, 관심사들 사이에서 균형을 잡는데 도움이 된다.
좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.
우리는 시스템을 수평적 계층으로 분할하면서 동시에 해당 계층을 가로지르는, 얇은 수직적인 유스케이스로 시스템을 분할할 수 있다.
이와 같이 결합을 분리하려면 주문 추가 유스케이스의 UI와 주문 삭제 유스케이스의 UI를 분리해야 한다.
시스템에서 서로 다른 이유로 변경되는 요소들의 결합을 분리하면 기존 요소에 지장을 주지 않고도 새로운 유스케이스를 계속해서 추가할 수 있게 된다.
유스케이스를 위해 수행하는 그 작업들은 운영에도 도움이 된다.
운영 측면에서 이점을 살리기 위해선 결합을 분리할 때 적절한 모드를 선택해야 한다.
많은 아키텍트가 마이크로서비스라고 하는 구분 기준은 모호한 면이 있다.
실제로 서비스에 기반한 아키텍처를 흔히들 서비스 지향 아키텍처라고 부른다.(Service-Oriented Architecture)
기억해야 할 점은 좋은 아키텍처는 선택권을 열어 둔다는 사실이다.
결합 분리 모드는 이러한 선택지 중 하나다.
컴포넌트가 완전히 분리되면 팀 사이의 간섭은 줄어든다.
유스케이스와 계층의 결합이 분리되면 배포 측면에서도 고도의 유연성이 생긴다.
아키텍츠는 종종 함정에 빠지곤 한다. 전적으로 중복에 대한 공포로부터 발생하는 함정이다.
진짜 중복
우발적인 중복
유스케이스를 수직으로 분리할 때 이러한 문제와 마주칠 테고, 이들 유스케이스를 통합하고 싶다는 유혹을 받게 될 것이다. 왜냐하면 이들 유스케이스가 서로 비슷한 화면 구조, 비슷한 알고리즘, 그리고 비슷한 데이터베이스 쿼리와 스키마를 가지기 때문이다.
단순히 서비스 수준에서의 분리를 기본 정책으로 삼는 게 해결책이 될 수 있음.
이 방식은 비용이 많이 들고, 결합이 큰 단위에서 분리된다는 문제가 있다.
서비스 수준의 결합 분리가 지닌 또 다른 문제점은 개발 시간 측면뿐 아니라 시스템 자원 측면에서도 비용이 많이 든다는 사실이다.
컴포넌트가 서비스화될 가능성이 있다면 나는 컴포넌트 결합을 분리하되 서비스가 되기 직전에 멈추는 방식을 선호한다.
좋은 아키텍처는 시스템에 모노리틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야한다.
시스템의 결합 분리 모드는 시간이 지나면서 바뀌기 쉬우며, 뛰어난 아키텍트라면 이러한 변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다는 점이다.