05 아키텍처 (3)

17장. 경계: 선 긋기

소프트웨어 아키텍처는 선(=경계)을 긋는 기술이다. 경계는 소프트웨어 요소를 서로 분리한다.

프레임워크, 데이터베이스, 웹서버, 유틸리티 라이브러리, 의존성 주입 등 유스케이스와 아무런 관련이 없는 시스템의 업무 요구 사항에 대해 너무 일찍 결정을 내리면 결합(coupling)이 발생하고, 인적 자원의 효율을 떨어뜨린다.

좋은 시스템 아키텍처는 이런 결정에 의존하지 않고, 결정에 따른 영향이 크지 않게 만든다.

---

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

관련이 있는 것와 없는 것 사이에 선을 긋는다.

GUI, 업무규칙, 데이터베이스는 서로 관련이 없으므로 각각 선을 긋는다.

 

업무규칙은 데이터를 가져오고 저장할 때 사용할 함수 집합이 있다는 사실만 알면 된다. 이러한 함수 집합을 통해서 데이터베이스를 인터페이스 뒤로 숨길 수 있다.

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

이 그림에서 DatabaseAcesss로 향하는 화살표는 없다. 즉 DatabaseAcess가 존재한다는걸 알고있는 클래스는 없다.

다음으로 많은 업무 규칙이 포함된 컴포넌트, 데이터베이스와 데이터베이스 접근 클래스를 포함하는 컴포넌트를 살펴보자.

화살표의 방향을 통해 BusinessRules에게 있어 Database는 문제가 되지 않지만, Database는 BusinessRules 없이는 존재할 수 없다는 사실을 알 수 있다. Database 컴포넌트는 다양한 구현체로 교체될 수 있다.

입력과 출력은?

우리는 시스템의 행위를 입출력이 지닌 행위적 측면에서 생각하는 경향이 있다.

예를 들어 비디오 게임에서 사용자 경험은 화면, 마우스, 버튼, 음향 등의 인터페이스에 의해 좌우된다.

하지만 모델은 인터페이스를 전혀 필요로 하지 않으며, 게임이 화면에 출력되지 않더라도 모델은 게임에서 발생하는 모든 이벤트를 모델링하면서 주어진 역할을 수행한다.

인터페이스는 모델에게 중요하지 않다. 중요한 것은 업무 규칙이다.

 

따라서 이번에도 GUI와 BusinessRules 컴포넌트가 경계선에 의해 분할된다는 사실을 볼 수 있다.

플러그인 아키텍처

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

핵심적인 업무 규칙과 다양한 형태로 구현될 수 있는 나머지 컴포넌트는 독립적이다.

플러그인에 대한 논의

우리는 특정 모듈이 나머지 모듈에 영향을 받지 않기를 바란다.

시스템을 플러그인 아키텍처로 배치하면 변경이 전파될 수 없는 방화벽을 생성할 수 있다.

경계는 변경의 축이 있는 지점에 그어진다. GUI와 업무 규칙은 다른 시점에 다른 속도로 변경되므로 경계가 필요하다.

업무규칙과 의존성 주입 프레임워크 사이도 마찬가지다.

이 역시도 단일 책임 원칙에 해당하며, 단일 책임 원칙은 어디에 경계를 그어야할지 알려준다.