아키텍처 - 경계

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 개요

소프트웨어 아키텍처는 경계 설정을 잘해야 한다. 경계는 요소를 분리하며, 특정 요소들끼리 서로 알지 못하게 한다. 어떤 경계 설정은 초기에 이루어 지며 어떤 경계 설정은 나중에 이루어진다.

 

초기의 섣부른 결정은 불필요한 결합을 만든다. 유스케이스와 관련없는 결정들, 예를 들어 프레임워크, DB, 웹 서버, 유틸리티 라이브러리등이 있다. 좋은 아키텍처는 이런 요소를 부수적인것으로 만들 수 있으며, 이런 결정을 최대한 미룬다. 또한 이런 결정이 변경됨에 따른 영향도가 크지 않게 만든다.

 

경계는 관련이 있는 것과 없는 것 사이에 긋는다. GUI, 업무규칙, 데이터베이스 이 세 가지는 서로 관련이 없기 때문에 이 사이에는 경계가 존재해야 한다.

---

- 업무규칙과 데이터베이스

업무규칙에 의해 데이터가 생성되고, 데이터를 불러와서 업무규칙을 수행하는데 왜 관련이 없느냐고 생각할 수도 있다. 하지만 데이터베이스는 업무규칙이 사용할 수 있는 도구에 불과하다.

위 다이어 그램을 보자. Business Rules는 Database Interface를 통해 데이터를 조회 및 저장한다. DatabaseAccess는 해당 인터페이스를 구현하며, 실제로 Database를 조작한다. 업무규칙이 알아야 하는 것은 데이터 조회 및 저장에 쓰이는 함수들이 있다는 정도만 알아야 한다.

 

그렇다면 우리가 주제로 다루고 있는 경계는 어디에 위치해야 할까?

위 다이어 그램에서 경계(Boundary) 는 Database Access와 Database Interface 사이에 존재한다. 왜 하필이면 이 사이에 존재해야 할까? 

 

Business Rules과 Database Interface 사이에 존재하면 안되는걸까? 오히려 이름으로만 보면 Database 라는 이름이 있으니 일리가 있어 보인다. 하지만 앞의 글을 제대로 보았던 사람이라면 왜 여기여야 하는지 알 수 있다.

 

Business Rules와 Database Interface를 Business Rules 라는 컴포넌트로 묶고, Database Access와 Database를 Database 컴포넌트로 묶고 그림을 다시 한번 보자.

저수준의 컴포넌트인 Database Component가 고수준의 컴포넌트인 Business Rules Component 에 의존하고 있다. 만약 Database Interface와 Business Rules 사이에 경계를 설정했다면 고수준의 컴포넌트가 저수준의 컴포넌트에 의존했을 것이다.

 

여기서 이 화살표 방향이 무엇을 의미할까? 저수준의 컴포넌트가 고수준의 컴포넌트에 의존하면 뭐가 좋을까? 고객이 Oracle을 사용하다가 재정적 부담을 줄이기 위해 무료 데이터베이스로 변경한다고 해보자. 위와 같이 설계했다면 중요한 업무규칙에 영향을 미치지 않고 Database 컴포넌트를 변경할 수 있게 된다.

---

- 업무규칙과 GUI

고객은 시스템이 빨리 만들어 지길 원한다. 만약 우리가 업무규칙을 구현하고 그에 따른 데이터 저장 및 조회로직도 다 구현했다면 개발자들은 "이제 View단만 구현하면 되므로 거의 다 했다."라고 생각할것이다. 하지만 고객은 눈에 보이는게 없으므로 "아직 시작도 안했다"고 생각하거나 "별로 진척이 안됐네"고 생각한다. 

 

고객이 알아주면 정말 베스트이지만 그런 사람을 만날 가능성은 희박하다. 다만 고객은 그렇게 생각하지 않아도 개발자라면 당장 눈에 보이는 GUI 보다 업무규칙이 중요하다는 사실을 알아야 한다.

데이터베이스와 마찬 가지로 GUI 컴포넌트는 업무규칙 컴포넌트에 의존한다. 따라서 추가적인 다른 종류의 인터페이스가 필요하다면 얼마든지 추가하거나 교체할 수 있어야 하며, 이때 업무규칙에 영향을 주지 않아야 한다.

---

- 플러그인 아키텍처

여태까지 알아본 GUI, 업무규칙, DB간 관계를 한꺼번에 그리면 아래와 같은 다이어그램이 된다.

핵심적인 업무규칙은 분리된 채 GUI와 DB 컴포넌트는 플러그인 형태와 같이 설계되었다. 인터페이스를 콘솔이나 웹 기반으로 변경하거나 DB를 NoSQL이나 파일시스템으로 변경하는것도 가능하다. 물론 실제 구현은 말처럼 간단하진 않지만, 그래도 핵심적인 업무규칙에는 최대한 영향을 적게 줄 것이다.

---

- 결론

경계를 설정하려면 시스템을 컴포넌트 단위로 분할해야한다. 업무규칙이 중심 컴포넌트가 되며, 나머지는 유연하게 변경할 수 있는 컴포넌트가 된다. 이때 반드시 화살표(의존성)은 업무규칙을 향하도록하여 저수준의 컴포넌트가 고수준의 컴포넌트를 향해야 한다.