[Clean Architecture 정리] 17장. 경계: 선 긋기

경계: 선 긋기

소프트웨어 아키텍처는 시스템 요소를 분리하는 경계를 긋는 기술이며, 이 경계로 인해 경계 한 쪽의 요소가 다른 한쪽의 요소에 대해서 알지 못한다. 경계를 긋는 행위의 목표는 인적 자원에 드는 비용을 최소화하는 것이다. 

 

인적 자원의 비용을 높이는 요인 중 결합(coupling)이 있으며, 특히 너무 이른 결정에 의한 결합이 비용을 높이게 된다.

 

 

두 가지 슬픈 이야기

본 잘못된 아키텍처의 사례로 두 회사의 이야기를 다루고 있다.

 

첫번째는 데스크톱 GUI 애플리케이션을 개발한 P사의 이야기이다.

90년대 후반 웹 어플리케이션이 대세를 이루자 P사는 자사 제품을 웹으로 변환하려는 작업에 착수했다. 이러한 과정에서 P사는 이른 결정을 하게 되었고, 결국 엄청난 개발 비용으로 인한 비극을 맞게 되었다는 이야기이다.

 

두번째는 회사 차량을 관리해주는 W사에 대한 이야기이다.

W사는 SOA를 약속하는 일련의 도구들을 너무 일찍 채택하여 적용했고 모든 서비스 사이의 결합으로 안 좋은 결과를 맞이하게 된다.

책의 내용을 빌리자면 지옥이 더 더 나은 곳처럼 보인다고 한다.(ㅋㅋ)

 

 

FitNesse

저자와 저자의 아들이 개발한 소프트웨어의 대한 이야기이다.

개발하고자 했던 시스템을 UI, 업무 규칙, 데이터베이스 계층으로 적절하게 나누었고, 결국 데이터베이스에 대한 선택을 마지막까지 미룰 수 있었다는 이야기였다.

 

이 사례를 읽으면서 최근 진행하고 있는 프로젝트가 많이 생각났다. 
머신러닝을 위한 간단한 API 서버가 필요했고, 프로젝트 시작 단계부터 데이터베이스를 정한 상태에서 시작했기 때문에 컴포넌트 분리는 물론 인터페이스 조차 존재하지 않도록 만들었다.
책 내용을 읽으면서 굳이 데이터베이스가 필요했을까? 위 사례처럼 파일 형식으로 저장했어도 되지 않았을까하는 생각이 들었다.
우선은 인터페이스부터 만들어서 변경에 대비해야겠다는 생각을 하고 바로 적용했다.

 

 

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

관련이 있는 것과 없는 것 사이에 선을 긋는다. 일반적으로 앞 장에서 살펴본 것처럼 GUI, 업무 규칙, 데이터베이스 간 경계를 만들 수 있다.

데이터베이스와 업무규칙의 경우 위처럼 경계를 구분할 수 있다.

 

이를 컴포넌트로 표현하면 위와 같다.

업무 규칙은 고수준 컴포넌트이다. 데이터베이스는 세부사항이며 저수준 컴포넌트이다. 업무 규칙 컴포넌트에 데이터베이스 인터페이스를 두어 의존을 역전시켜 저수준 컴포넌트가 고수준 컴포넌트를 의존하도록 한다.

이로인해, 업무 규칙은 데이터베이스에 대해 알지 못하고, 데이터베이스가 변경되더라도 영향을 받지 않는다.

 

 

플러그인 아키텍처

UI에도 데이터베이스와 같은 방식을 적용하면, UI, 업무 규칙, 데이터베이스는 위와 같은 아키텍처를 갖게 된다. 이러한 패턴은 시스템에서 서드 파티 플러그인을 사용할 수 있게 만든 플러그인 아키텍처와 동일하다.

 

소프트웨어 개발 기술의 역사는 플러그인을 쉽게 생성, 확장, 유지보수하도록 아키텍처를 확립할 수 있게 만드는 방법에 대한 이야기라고 한다. 선택적이거나 다양한 형태로 구현될 수 있는 나머지 컴포넌트(UI, 데이터베이스)로부터 핵심적인 업무 규칙을 분리하고, 독립적으로 존재하도록 만든다.

 

서적 : http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24