Table of Contents
소프트웨어 아키텍처는 선을 긋는 기술이며, 이 선을 경계(boundary)라고 부른다.
경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.
초기에 그어지는 선들은 가능한 오랫동안 결정을 연기시키기 위해, 그래서 이들 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰인다.
아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이라는 사실을 상기하자.
그렇다면 인적 자원의 효율을 떨어뜨리는 요인은 무엇일까?
바로 결합(coupling)이다. 특히 너무 일찍 내려진 결정에 따른 결합이다.
어떤 종류의 결정이 이른 결정일까?
바로 시스템의 업무 요구사항, 즉 유스케이스와 아무런 관련이 없는 결정이다.
좋은 아키텍처는 이러한 결정을 가능한 최후의 순간에 내릴 수 있게 해주며, 결정에 따른 영향이 크지 않게 만든다.
어떻게 선을 그을까? 그리고 언제 그을까?
관련이 있는 것과 없는 것 사이에 선을 긋는다.
GUI는 업무 규칙과는 관련 없기 때문에 이 둘 사이에 선이 있어야 한다.
데이터베이스와 GUI와는 관련 없으므로 선이 있어야 한다.
데이터베이스와 업무 규칙과 관련이 없으므로 선이 있어야 한다.
하지만, 데이터베이스는 업무 규칙과 서로 떼어놓을 수 없는 관계라고 배운 사람이 많다.
하지만 잘못된 생각이다.
데이터베이스는 업무 규칙이 간접적으로 사용할 수 있는 도구다.
업무 규칙은 스키마, 쿼리 언어, 또는 데이터베이스와 관련된 나머지 세부사항에 대해 어떤 것도 알아서는 안 된다.
업무 규칙이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실이 전부다.
이러한 함수 집합을 통해서 우리는 데이터베이스를 인터페이스 뒤로 숨길 수 있다.
입력과 출력은?
입력과 출력은 중요하지 않다.
인터페이스 뒤에는 인터페이스를 조작하는 모델이 존재한다.
더 중요한 사실은 모델은 인터페이스를 전혀 필요로 하지 않는다는 점이다.
중요한 것은 업무 규칙 이다.
플러그인 아키텍처
데이터베이스와 GUI에 대해 내린 두 가지 결정을 하나로 합쳐서 보면 컴포넌트 추가와 관련된 일종의 패턴이 만들어진다.
이 패턴은 시스템에서 서드 파티 플러그인을 사용할 수 있게 한 바로 그 패턴과 동일하다.
사실 소프트웨어 개발 기술의 역사는 플러그인을 손쉽게 생성하여, 확장 가능하며 유지보수가 쉬운 시스템 아키텍처를 확립할 수 있게 만드는 방법에 대한 이야기다.
플러그인에 대한 논의
시스템을 플러그인 아키텍처로 배치함으로써 변경이 전파될 수 없는 방화벽을 생성할 수 있다.
GUI가 업무 규칙에 플러그인 형태로 연결되면 GUI에서 발생한 변경은 절대로 업무 규칙에 영향을 미칠 수 없다.
경계는 변경의 축이 있는 지점에 그어진다.
경계의 한쪽에 위치한 컴포넌트는 경계 반대편의 컴포넌트와는 다른 속도로 그리고 다른 이유로 변경된다.
이 역시도 순전히 단일 책임 원칙에 해당한다.
단일 책임 원칙은 어디에 경계를 그어야 할지를 알려준다.
결론
소프트웨어 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다.
컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 업무를 향하도록 이들 컴포넌트의 소스를 배치한다.
의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치한다.