경계: 선 긋기

소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계(boundary)라 부른다. 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다. 어떤 경계는 시스템 초기에 생기기도 하며 어떤 것은 매우 나중에 그어지기도 한다.

아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이다. 인적 자원의 효율을 떨어트리는 요인은 바로 결합(coupling)이다. 특히, 너무 일찍 내려진 결정에 따른 결합.

어떤 종류의 결정이 이른 결정인가? 바로 유스케이스와 아무런 관련이 없는 세부사항들이다. 프레임워크, DB, 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등이 여기에 포함된다.

좋은 아키텍처는 이런 결정에 의존하지 않고 가능한 늦게 결정을 내릴 수 있게 하며 결정에 따른 영향이 크지 않게 만든다.

어떻게 선을 그을까? 그리고 언제 그을까?

관련이 있는 것과 없는 것 사이에 선을 긋는다. UI는 업무 규칙과 관련 없기 때문에 이 둘 사이에는 반드시 선이 있어야 한다. DB와 UI도 마찬가지고, DB와 업무 규칙도 그렇다.

DB와 업무 규칙이 관련 없다고 생각할 수도 있지만 DB는 업무 규칙이 간접적으로 사용할 수 있는 도구다. 업무 규칙은 스키마, 쿼리 언어, DB와 관련된 세부사항에 대한 어떤 것도 알아서는 안된다.

업무 규칙이 알아야할 것은 데이터 조회 및 저장에 쓸 수 있는 함수들이 있다는 것 뿐이다. 인터페이스를 통해서 DB를 숨길 수 있다.

경계선은 상속 관계를 횡단하면서 DB Interface 바로 아래에 그어진다.

화살표 방향에 주목하자. DB는 BusinessRules를 알고 있다. 반면 BusinessRules는 DB에 대해 알지 못한다. 이는 DB Interface는 BusinessRules와 같은 레이어에 있고 DB Access는 DB와 같은 레이어에 있음을 알 수 있다.

이 선의 방향이 중요하다. BusinessRules에게 DB는 문제가 되지 않지만 DB는 BusinessRules 없이 존재할 수 없다. 이는 DB 뿐 아니라 UI에서도 마찬가지로 적용할 수 있다.

플러그인 아키텍처

이러한 구조를 살펴보면 컴포넌트 추가와 관련한 일종의 패턴이 만들어진다.

소프트웨어 개발 기술의 역사는 플러그인을 쉽게 생성하여 확장 가능하며 유지보수가 쉬운 시스템 아키텍처를 만드는 방법에 대한 이야기다.

이러한 설계는 UI와 DB를 플러그인으로 다루기 때문에 임의의 다른 기술로 갈아끼울 수 있다.

결론

경계는 변경의 축(axis of change)이 있는 지점에 그어진다. 경계를 두고 각각의 컴포넌트는 각자의 속도와이유로 변경된다. 이 역시 단일 책임 원칙에 해당한다. 단일 책임 원칙은 어디에 경계를 그어야 할지를 알려준다.

경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다. 일부는 핵심 업무 규칙이고 일부는 플러그인, 어떤 것들은 필수 기능을 포함할 수도 있겠다. 그 다음에 컴포넌트 사이의 화살표가 핵심 업무 규칙을 향하도록 컴포넌트를 배치해야 한다.

이는 의존성 역전 원칙과 안정된 추상화 원칙을 응용한 것이다.