경계
소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계라고 부른다.
경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다.
어떻게 선을 그을까? 그리고 언제 그을까?
관련이 있는 것과 없는 것 사이에 선을 긋는다.
business rule이 알아야 할 것은 데이터를 가져오고 저장할 때 사용할 수 있는 함수 집합이 있다는 사실이 전부이다.
경계선은 database interface 바로 아래에 만들어진다.
business rule에게 database는 문제가 되지 않지만, database는 business rule 없이는 존재할 수 없다.
입력과 출력은?
입력과 출력은 중요하지 않다.
GUI는 다른 종류의 인터페이스로 교체할 수 있다.
플러그인 아키텍처
소프트웨어 개발 기술의 역사는 플러그인을 손쉽게 생성하여, 확장 가능하며 유지보수가 쉬운 시스템 아키텍처를 확립할 수 있게 만드는 방법에 대한 이야기다. 나머지 컴포넌트로부터 핵심적인 business rule은 분리되어 있고, 독립적이다.
GUI가 business rule에 플러그인 형태로 연결되면 GUI에서 발생한 변경은 절대로 business rule에 영향을 미칠 수 없다.
결론
소프트웨어 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야 한다.
정책과 수준
소프트웨어 시스템이란 정책을 기술한 것이다.
동일한 이유로 동일한 시점에서 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야 한다.
좋은 아키텍처라면 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야한다. 저수준 컴포넌트가 고수준 컴포넌트에 의존하도록 설계되어야 한다.
수준
수준(level)을 엄밀하게 정의하자면 입력과 출력까지의 거리이다.
입력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다.
고수준 정책(입력과 출력에서부터 멀리 떨어진 정책)은 저수준 정책에 비해 덜 빈번하게 변경되고, 더 중요한 이유로 변경되는 경향이 있다.
소스 코드 의존성의 방향이 고수준 정책을 향하도록 분리했다면 변경의 영향도를 줄일 수 있다.
Reference
Clean Architecture - Robert C. Martin
