소프트웨어 아키텍처의 핵심은 선을 긋는 기술이며 책에서는 이것을 "경계" 라고 불렀다. 이 경계를 통해 업무적 로직을 오염시키지 못하도록 하는 목적으로 쓰인다. 하지만 인적 자원의 효율을 떨어트리는 가장 큰 요인은 결합이다. (너무 일찍 내려진 결정에 따른 결합) 아키텍처를 너무 일찍 결정해버리고 너무 다양한 시스템이 얽혀있어 문제가 발생할 수 있다.
FitNesse라는 서비스를 만드는 중의 과정
오픈된 웹서버를 사용하지 않고 자신들에게 맞는 웹서버를 직접 작성하였다. 기본 뼈대만 갖춘 웹 서버는 단순한 소프트웨어이기 때문에 구현이 간단하다. 또한, 어떠한 웹 프레임워크를 사용할 것인지에 대한 결정을 나중으로 미룰 수 있다.
데이터베이스에 대해 고려하지 않는다. 인터페이스를 설계한 후 데이터 저장소에 접근하는 방법만을 정의해 놓고 어떠한 데이터베이스가 와도 상관없도록 설계하였다. 가장 초기에는 MYSQL 도입을 고려하였지만 이에 대한 결정은 나중으로 미뤘다.
- 시작은 데이터 저장은 하지 않고 텍스트를 html로 변환하는 단순 기능을 구현함.
- 그 후 변환만으로는 안되서 저장에 대한 고민을 하는 데 우선적으로 힙메모리 디비를 사용(메모리에 데이터 저장)
- 메모리에만 데이터를 넣는 것 또한 부족해서 디비를 고려하였지만 메모리에 있는 데이터를 파일로 저장 하는 것은 매우 쉬워 우선 파일로 저장
- 초기에는 MySQL로 영속화를 하는 것을 고려하였지만 파일로 저장만 하여도 되었기 때문에 MySQL을 도입하는 방안은 폐기되었다.
즉 , FitNesse를 설계할때에 데이터베이스와 업무 규칙 사이에 "경계선"을 명확히 함으로서 데이터베이스 접근에 대한 것을 업무 규칙에서 완전히 분리시킬 수 있었다. 덕분에 데이터베이스 스키마나 설정과 같은 문제에서 벗어날 수 있었으며 기능 자체 테스트에 더 집중이 가능했다. 경계선을 명확히 함으로서 시간을 절약할 수 있었다.
GUI와 업무 규칙과는 관련이 없다. 따라서 선이 존재해야한다.
데이터베이스와 GUI와도 관련이 없다. 이 사이에도 선이 존재한다.
사람에 따라서 데이터베이스와 업무 규칙은 때놓을 수 없다고 생각하는 사람이 있을 수 있지만 엄밀히 따지면 데이터베이스는 업무규칙이 __간접적__으로 사용할 수 있는 도구이지 업무 규칙과는 상관이 없다.
아래 그림을 보자.
그림을 보면 데이터베이스 자체는 인터페이스 뒤에 숨어 비지니스 룰이 데이터베이스를 사용하는 방식이다.
(대부분의 데이터베이스 구현체가 비슷한 패턴을 가진다)
경계선은 데이터베이스 인터페이스와 데이터베이스 Access 사이에 그어진다.
위 그림을 더 단순화 시키면 다음과 간다.
화살표 방향을 보면 DB는 비지니스 룰에 대해서 알고있지만 비지니스 룰은 디비에 대해서 알지 못한다.
따라서 Interface는 비지니스 룰 컴포넌트에 해당된다는 것을 알 수 있다.
이렇게 경계선을 명확히 함으로서 경계를 명확히 할 수 있다.
사실 GUI는 비지니스 룰과는 관련이 없다. 단지 보여주는 것이 뿐이지 입력과 출력은 중요하지 않다.
따라서, GUI 또한 인터페이스와 분리되어 있으며 아래와 같이 경계가 그어진다.
따라서, GUI는 언제든 다른 종류의 인터페이스와 교체가 가능하며 비지니스 룰과는 상관 없다.
GUI가 비지니스 룰을 신경쓰지 비지니스 룰이 GUI를 신경쓰지 않는다.
(우리가 이전에 살펴 본 것 처럼 관련성이 낮은 컴포넌트가 관련성이 높은 컴포넌트에 의존한다.)
우리가 앞서 살펴본 두 가지 패턴으로 알 수 있는 것이 있다. 이렇게 플러그인 방식으로 경계를 잘 설정해 놓으면 데이터베이스나 GUI가 변경되더라도 비지니스 룰에는 영향을 끼치지 않을 수 있다는 점이다. 따라서 이러한 플러그인 구조를 이용하여 구조를 더 자유롭게 만들어 줄 수 있다.