17장 - 경계: 선 긋기

경계란?

경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막습니다.

프로젝트 초기의 그어지는 선은 가능한 결정을 연기시키기 위한 목적으로 사용됩니다.

 

 

W사, P사의 아키텍트가 너무 이르게 결정을 내려 개발 비용이 가중된 사례 이야기

 

Finesse

초기에 MySQL을 염두에 두고 있었으나 인터페이스와 스텁을 만들어두고 최대한 결정을 연기하였습니다.

이후에 영속성을 구현해야하는 시점에 MySQL을 다시 한번 고민하였으며, 단기적으로는 필요 없다는 결정을 내리게 되었으며 추후에는 완전히 폐기하였습니다.

 

하지만 추후에 고객이 MySql에 저장하고 싶다는 요구사항을 보였고, 하루 만에 도입할 수 있게 되었습니다.

이렇게 업무 규칙과 데이터베이스 사이에 경계선을 통해 이런일이 가능했습니다.

 

스키마, 쿼리, 패스워드, 테스트를 느리게 만드는 이런 고약한 문제들은 사라졌습니다.

궁극적으로 엄청난 시간을 절약해주었으며 좋은 아키텍트라면 반드시 해야 하는 일입니다.

 

경계를 긋는 방법

GUI와 업무 규칙은 관련이 없습니다.

GUI와 데이터베이스 관련이 없습니다.

 

이에 동의하지 않을 수 있습니다.

업무 규칙이 구체화된 것이 데이터베이스라고 확신하는 사람도 있습니다.

 

하지만 데이터베이스는 업무 규칙을 간접적으로 사용할 수 있는 도구이며, 세부사항에 대해 어떤 것도 알아서는 안됩니다.

 

이때 경계선은 바로 Database Interface를 기준으로 긋습니다.

 

이를 통해 BusinessRules에는 어떠한 데이터베이스도 사용할 수 있게 되며, Database는 다양한 구현체로 교체될 수 있습니다.

 

마찬자기로 GUI와 BusinessRules에서도 GUI는 다른 종류의 인터페이스로 얼마든지 교체할 수 있으며, BusinessRules는 전혀 개의치 않습니다.

 

즉, 관련성이 낮은 컴포넌트가 관련성이 높은 컴포넌트에 의존합니다.

(중요한 것은 업무규칙입니다)

 

플러그인 형태

서드 파티 라이브러리와 같이 플러그인 형태를 손쉽게 생성하고 확장 가능하고 유지보수가 쉽습니다.

플러그인 구조를 가정한 채 시작함으로써, 변경 작업을 현실성 있도록 만들 수 있습니다.

 

GUI와 업무 규칙은 다른 시점에 다른 속도로 변경되므로 둘 사이에는 반드시 경계가 필요합니다.

이 역시도 순전히 단일 책임 원칙에 해당합니다.

단일 책임 원칙은 어디에 경계를 그어야 할지 알려줍니다.

 

또한 의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치되어야 합니다.