SW 아키텍처는 선을 긋는 기술이며, 나는 이러한 선을 경계라고 부른다.
경계는 SW 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 한다.
이들 선 중 일부는 프로젝트 초기에 그어지며, 심지어 코드가 전혀 작성되기도 전에 그어진다.
반대로 어떤 선들은 매우 나중에 그어진다.
아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이라는 사실을 상기하자.
그렇다면 인적 자원의 효율을 떨어뜨리는 요인은 무엇일까? -> 결합이다.
어떤 종류의 결정이 이른 결정일까? 바로 시스템의 업무 요구사항(유스케이스)와 아무런 관련이 없는 결정이다.
프레임워크, DB, 웹 서버, 유틸 라이브러리, 의존성 주입에 대한 결정 등
좋은 아키텍처란 이러한 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처다.
좋은 시스템 아키텍처는 이런 결정에 의존하지 않는다.
어떻게/언제 선을 그을까?
관련이 있는 것과 없는 것 사이에 선을 긋는다.
GUI는 업무 규칙과는 관련 없기 때문에, 이 둘 사이에는 반드시 선이 있어야 한다.
DB는 GUI와는 관련이 없으므로, 이 둘 사이에도 반드시 선이 있어야 한다.
DB는 업무 규칙과 관련이 없으므로, 이 둘 사이에도 선이 있어야 한다.
-> 이 부분에 동의하지 않는 사람들도 있을 것이다.
-> 특히 업무 규칙이 DB에 신경 쓰지 않아야 한다는 부분에서 말이다.
-> DB는 업무 규칙과 서로 떼어놓을 수 없는 관계라고 배웠다.
-> 심지어 업무 규칙이 구체화된 것이 바로 DB라고 확신하는 사람도 있다.
이는 잘못된 생각이다. DB는 업무 규칙이 간접적으로 사용할 수 있는 도구다.
업무 규칙은 스키마, 쿼리 언어, 또는 DB와 관련된 나머지 세부사항에 대해 어떤 것도 알아서는 안된다.
업무 규칙이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실이 전부다.
이러한 함수 집합을 통해서 우리는 DB를 인터페이스 뒤로 숨길 수 있다.
BusinessRules는 DBInterface를 사용하여 데이터를 로드하고 저장한다.
DBAccess는 DataBaseInterface를 구현하며, 실제로 DB를 조작한다.
이 도표에서 클래스와 인터페이스는 상징적이다.
실제 App에서는 업무 규칙과 관련된 수많은 클래스들, DB 인터페이스와 관련된 수많은 클래스들 그리고 DB 접근을 구현한 수많은 구현체가 존재한다.
그렇더라도 이 모두는 이 패턴을 거의 동일하게 따른다.
경계선은 어디에 있는가?
DBAccess에서 출발하는 두 화살표에 주목하자.
두 화살표는 DBAccess 클래스로부터 바깥쪽으로 향한다.
즉, 이 도표에서 DBAccess가 존재한다는 사실을 알고 있는 클래스는 없다는 뜻이다.
조금 물러나서 보자. 많은 업무 규칙이 포함된 컴포넡트, DB와 DB 접근 클래스를 포함하는 컴포넌트를 살펴보려고 한다.
화살표 방향에 주목하자.
DB는 BusinessRules에 대해 알고 있다.
BusinessRules는 DB에 대해 알지 못한다.
이는 DBInterface 클래스는 BusinessRules 컴포넌트에 속하며, DBAccess 클래스는 DB 컴포넌트에 속한다는 사실을 의미한다.
이 선의 방향이 중요하다. BusinessRules에게 있어 DB는 문제가 되지 않지만, DB는 BusinessRules 없이는 존재할 수가 없다.
이러한 사실이 이상하게 보인다면 하나만 기억하자.
DB 컴포넌트는 BusinessRules가 만들어낸 호출을 DB의 쿼리 언어로 변환하는 코드를 담고 있다.
BusinessRules에 대해 알고 있는 코드는 바로 이 변환 코드다.
두 컴포넌트 사이에 이러한 경계선을 그리고 화살표의 방향이 BusinessRules를 향하도록 만들었으므로, BusinessRules에서는 어떤 종류의 DB도 사용할 수 있다.
DB 컴포넌트는 다양한 구현체로 교체될 수 있으며, BusinessRules는 조금도 개의치 않는다.
DB는 오라클, MySQL 등으로 구현할 수 있다. 업무 규칙은 전혀 개의치 않는다.
그리고 이 같은 사실은 DB에 대한 결정을 연기할 수 있으며, DB를 결정하기에 앞서 업무 규칙을 먼저 작성하고 테스트하는 데 집중할 수 있음을 의미한다
입력과 출력은?
개발자와 고객은 종종 시스템이 무엇인지에 대해 혼란스러워한다.
GUI를 보고선 GUI가 시스템이라고 생각하곤 한다.
이들은 시스템을 GUI 측면에서 정의하므로, 처음부터 GUI가 동작하는 모습을 반드시 볼 수 있어야 한다고 믿는다.
하지만 입력과 출력은 중요하지 않다.
이 원칙은 처음에는 이해하기 힘들다. 우리는 시스템의 행위를 입출력이 지닌 행위적 측면에서 생각하는 경향이 있다.
EX)
- 비디오 게임에서 화면, 마우스, 음향의 인터페이스, 그 뒤에 모델(데이터 구조와 함수 들)이 있다는 것을 잊는다.
- 사실 UI가 없이도 게임을 충분히 진행된다.
- 중요한 것은 업무 규칙이다.
따라서 이번에도 GUI와 BusinessRules 컴포넌트가 경계선에 분할된다는 사실을 볼 수 있다.
관련성이 낮은 컴포넌트가 관련성이 높은 컴포넌트에 의존한다는 사실을 다시 한번 볼 수 있다.
화살표는 어느 컴포넌트가 어떤 컴포넌트를 알고 있는지를, 그래서 어느 컴포넌트가 어느 컴포넌트를 신경 쓰는지를 보여준다.
플러그인 아키텍처
DB와 GUI에 대해 내린 두 가지 결정을 하나로 합쳐서 보면 컴포넌트 추가와 관련된 패턴이 만들어진다.
이 패턴은 시스템에서 서드파티 플러그인을 사용할 수 있게 한 그 패턴과 동일하다.
사실 SW 개발 기술의 역사는 플러그인을 손쉽게 생성하여, 확장 가능하며 유지보수가 쉬운 시스템 아키텍처를 확립할 수 있게 만드는 방법이다.
선택적이거나 다양한 형태로 구현가능한 컴포넌트로부터 핵심적인 업무 규칙은 분리 되어있고, 독립적이다.
이 설계에서 UI는 플러그인 형태로 고려되었기에, 수많은 종류의 UI를 연결할 수 있게 된다.
웹 기반, 클라/서버 기반, SOA나 콘솔 기반 등등
DB에도 동일하게 적용할 수 있다.
NoSQL, MySQL, 오라클 등 어떤 종류의 DB 기술로도 대체 가능하다.
이러한 교체 작업은 사소한 일은 아닐 것이다.
시스템의 초기 배포가 웹 기반이었다면, 클라-서버 UI용 플러그인을 작성하는 것은 어렵다.
그렇다 하더라도 이렇게 선을 그음으로써 그 변경 작업을 최소화할 수 있다.
결론
SW 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다.
일부 컴포넌트는 핵심 업무 규칙에 해당한다.
나머지 컴포넌트는 플러그인으로 핵심 업무와는 직접적인 관련이 없지만 필수 기능을 포함한다.
그런 다음 컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 업무를 향하도록 이들 컴포넌트의 소스를 배치한다.
이는 의존성 역전 원칙과 안정된 추상화 원칙을 응용한 것임을 눈치챌 수 있어야 한다.
의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치된다.