[책 정리] 17장. 선긋기 - Clean Architecture

 

-

소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계(boundary)라고 부른다.

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

이들 선 중 일부는 프로젝트 수명 중 아주 초기에, 심지어 코드가 전혀 작성되기도 전에 그어지며, 어떤 선은 매우 나중에 그어진다.

초기에 그어지는 선들은 가능한 한 오랫동안 결정을 연기시키기 위해, 그래서 이들 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰인다.

 

 

-

아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이라는 사실을 상기하자.

그렇다면 인적 자원의 효율을 떨어뜨리는 요인은 무엇일까?

바로 결합(coupling)이다.

특히 너무 일찍 내려진 결정에 따른 결합이다.

 

 

-

어떤 종류의 결정이 이른 결정일까?

바로 시스템의 업무 요구사항, 즉 유스케이스와 아무런 관련이 없는 결정이다.

프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등이 여기 포함된다.

좋은 시스템 아키텍처란 이러한 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처다.

 

 

 

두 가지 슬픈 이야기

 

 

 

FitNesse

 

-

간단히 말해서 경게선을 긋는 행위는 결정을 늦추고 연기하는 데 도움이 되었고,

궁극적으로는 시간을 엄청나게 절약해주었으며, 골치를 썩지 않게 해주었다.

이것이 바로 좋은 아키텍처라면 반드시 해야 하는 일이다.

 

 

 

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

 

-

업무 규칙이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실이 전부다.

이러한 함수 집합을 통해서 우리는 db 인터페이스를 뒤로 숨길 수 있다.

 

 

-

BusinessRules 은 DB 에 대해 알지 못한다.

DatabaseInterface 클래스는 BusinessRule 컴포넌트에 속하며, DatabaseAccess 클래스는 Database 컴포넌트에 속한다.

이 선의 방향이 중요하다.

BusinessRules 에게 있어 DB 는 문제가 되지 않지만, DB 는  BusinessRule 에 없이는 존재할 수 없다는 사실을 알 수 있다.

DB 컴포넌트는 다양한 구현체로 교체될 수 있으며, BusinessRules 는 조금도 개의치 않는다.

 

 

 

입력과 출력은?

 

-

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

인터페이스는 모델에게 있어 중요하지 않다

중요한 것은 업무 규칙이다.

 

따라서 이번에도 마찬가지로 GUI 와 BusinessRules 컴포넌트가 경계선에 의해 분할된다.

GUI 가 BusinessRules 를 신경쓴다.

그럼 GUI 는 다른 종류의 인터페이스로 얼마든지 교체할 수 있다.

 

 

 

플러그인 아키텍처

 

-

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

선택적이거나 또는 수많은 다양한 형태로 구현될 수 있는 나머지 컴포넌트로부터 핵심적인 업무 규칙은 분리되어 있고, 또한 독립적이다.

 

 

 

플러그인에 대한 논의

 

-

우리가 시스템에서 갖추고자 하는 관계는 핵심은 주변 모듈에 영향을 받지 않지만, 핵심은 주변 모듈에 영향을 줄 수 있는 형태이다.

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

 

 

-

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

GUI 가 업무 규칙에 플러그인 형태로 연결되면 GUI 에서 발생한 변경은 절대로 업무 규칙에 영향을 미칠 수 없다.

경계는 변경의 축(axis of changes)이 있는 지점에 그어진다.

경계의 한쪽에 위치한 컴포넌트는 경계 반대편의 컴포넌트와는 다른 속도로, 그리고 다른 이유로 변경된다.

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

 

 

 

결론

 

-

소프트웨어 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다.

일부 컴포넌트는 핵심 업무 규칙에 해당한다.

나머지 컴포넌트는 플러그인으로, 핵심 업무와는 직접적인 관련이 없지만 필수 기능을 포함한다.

그런 다음 컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 업무를 향하도록 이들 컴포넌트의 소스를 배치한다.

 

이는 의존성 역전 원칙과 안정된 추상화 원칙을 응용향 것임을 눈치챌 수 있다.

의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치된다.