17. 선 긋기

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

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

아키텍트의 목표는 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것이라는 사실을 상기하자. 그렇다면 인적 자원의 효율을 떨어뜨리는 요인은 무엇일까? 바로 결합이다. 특히 너무 일찍 내려진 결정에 따른 결합이다.

어떤 종류의 결정이 이른 결정인가? 바로 시스템의 비즈니스 요구사항, 즉 유스 케이스와 아무런 관련이 없는 결정이다. 프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등이 여기 포함된다.

좋은 시스템 아키텍처란 이러한 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처이다. 좋은 아키텍처는 이런 결정에 의존하지 않는다. 좋은 시스템 아키텍처는 이러한 결정을 가능한 한 최후의 순간에 내릴 수 있게 해주며, 결정에 따른 영향이 크지 않게 만든다.

결정을 연기할 수 있다 = 기술적인 세부사항(프레임워크 등)에 영향을 받지 않는 구조이기 때문에 언제든지 이를 선택하거나 변경할 수 있는 상태라고 이해했음.

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

관련이 있는 것과 없는 것 사이에 선을 긋는다.

GUI는 비즈니스 로직과는 관련이 없기 때문에, 이 둘 사이에는 반드시 선이 있어야 한다.

데이터베이스는 GUI와 관련이 없고, 비즈니스 로직과도 관련 없으므로 선이 있어야 한다.

데이터베이스는 비즈니스 로직과 서로 떼어놓을 수 없는 관계라고 배운 사람이 많다. 이는 잘못된 생각이다. 데이터베이스는 비즈니스 로직이 간접적으로 사용할 수 있는 도구이다. 비즈니스 로직은 스키마, 쿼리 언어 또는 데이터베이스와 관련된 나머지 세부사항에 대해 어떤 것도 알아서는 안된다.

비즈니스 로직이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실이 전부다. 이러한 함수 집합을 통해서 우리는 데이터베이스를 인터페이스 뒤로 숨길 수 있다.

입력과 출력은?

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

모델은 인터페이스를 전혀 필요로 하지 않는다. 게임에서 화면이 출력되지 않더라도 모델은 게임에서 발생되는 모든 이벤트를 모델링 하면서 주어진 역할을 충실하게 수행한다. 인터페이스는 모델에게 있어 중요하지 않다. 중요한 것은 업무 규칙이다.

플러그인 아키텍처_

데이터베이스와 GUI에 대해 내린 두 가지 결정을 하나로 합쳐서 보면 컴포넌트 추가와 관련한 일종의 패턴이 만들어진다. 이 패턴은 시스템에서 서드파티 플러그인을 사용할 수 있게 한 바로 그 패턴과 동일하다.

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

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

결론

소프트웨어 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다. 일부 컴포넌트는 핵심 비즈니스 로직에 해당한다. 나머지 컴포넌트는 플러그인으로, 핵심 업무와는 직접적인 관련이 없지만 필수 기능을 포함한다. 그런 다음 컴포넌트 사이의 화살표가 특정 방향, 즉 핵심 비즈니스를 향하도록 이들 컴포넌트 소스를 배치한다.

이는 의존성 역전 원칙과 안정된 _추상화 원칠을 응용한 것이다. 의존성 화살표는 저 수준 세부사항에서 고 수준의 추상화를 향하도록 배치된다.