클린 아키텍처 5부. 아키텍처 - 1

15장. 아키텍처란?

---

• 소프트웨어 시스템의 아키텍처는 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다.
  • 모양은 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의소통 하는 방식에 따라 정해짐
  • 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어짐
• 이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다.
• 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것
  • 좋은 아키텍처는 시스템을 쉽게 이해, 개발, 유지보수, 배포할 수 있게 해준다.
• 아키텍처의 궁극적인 목표는 시스템의 수명과 관련된 비용은 최소화하고, 프로그래머의 생산성은 최대화하는 데 있음.

 

개발부터 유지보수까지

• 개발
  • 팀 규모가 적다면 아키텍처 관련 제약이 오히려 방해가 된다고 여길 가능성이 높아서 모노리틱 시스템을 개발할 수 있고 좋은 아키텍처가 결여된 이유가 바로 이 때문임.
  • 팀의 규모가 크다면 안정된 인터페이스를 잘 갖춘, 잘 설계된 컴포넌트 단위로 분리하지 않으면 개발이 진척되지 않음.
• 배포
  • 소프트웨어 시스템이 사용되려면 반드시 배포할 수 있어야함.
  • 배포 비용이 높을수록 시스템의 유용성은 떨어짐
  • 따라서 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는데 목표를 두어야함
• 운영
  • 시스템 아키텍처는 유스케이스, 기능, 시스템의 필수 행위를 일급(first-class) 엔티티로 격상시키고, 이들 요소가 개발자에게 주요 목표로 인식되도록 해야함
  • 이를 통해 시스템을 이해하기 쉬워지며, 개발과 유지보수에 큰 도움이 됨
• 유지보수
  • 유지보수는 모든 측면에서 봤을 때 소프트웨어 시스템에서 비용이 가장 많이 듬
  • 시스템을 컴포넌트로 분리하고, 안정된 인터페이스를 두어 서로 격리한다면
  • 미래에 추가될 기능에 대한 길을 밝혀 둘 수 있고 의도치 않은 장애 발생 위험을 줄일 수 있음

 

선택사항 열어두기

• 소프트웨어를 부드럽게 유지하는 방법은 선택사항(중요치 않은 세부 사항)을 가능한 한 많이, 오랫동안 열어두는 것이다.
• 모든 소프트웨서 시스템은 정책(policy)과 세부사항(detail)로 분해할 수 있다.
  • 정책은 모든 업무 규칙과 업무 절차를 구체화하고, 시스템의 진정한 가치가 살아있는 곳
  • 세부사항은 사람, 외부 시스템, 프로그래머가 정책과 소통할 때 필요한 요소지만, 정책이 가진 행위에는 조금도 영향을 미치지 않음
  • 세부사항에는 입출력 장치, 데이터베이스, 웹 시스템, 서버, 프레임워크, 통신 프로토콜 등이 있음
• 아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 세부사항은 정책에 무관하게 만드는 시스템을 구축하는 것
• 즉, 세부사항에 몰두하지 않은 채 고수준의 정책을 만들어 세부사항에 대한 결정을 미루어야한다.
  • 결정이 아직 내려가지지 않은 것 처럼 행동하며 여전히 결정을 오랫동안 연기하거나 변경할 수 있는 형태로 시스템을 만들어야 한다.
• 좋은 아키텍트는 결정되지 않은 사항의 수를 최대화 한다.

 

결론

• 좋은 아키텍트는 세부사항을 정책으로부터 신중하게 가려내고, 정책이 세부사항과 결합되지 않도록 엄격하게 분리한다.
• 이를 통해 정책은 세부사항에 관한 어떠한 지식도 갖지 못하며, 어떤 경우에도 세부 사항에 의존하지 않게 된다.
• 좋은 아키텍트는 세부 사항에 대한 결정을 가능한 오래 미룰 수 있는 방향으로 정책을 설계한다.

 

 

16장. 독립성

---

좋은 아키텍처는 다음을 지원해야한다.

• 시스템의 유스케이스
• 시스템의 운영
• 시스템의 개발
• 시스템의 배포

 

유스케이스

• 시스템 아키텍처는 시스템의 의도를 지원해야 한다.
• 아키텍트의 최우선의 관심사는 유스케이스이며, 아키텍처도 유스케이스가 최우선이다.
• 좋은 아키텍처는 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만드는 것이다.
• 이들의 행위를 시스템의 최상위 수준에서 알아볼 수 있으므로, 개발자가 일일이 찾아 헤메지 않아도 된다.

 

운영

• 운영 지원 관점에서 볼 때 아키텍처는 더 실질적이며 덜 피상적인 역할을 맡는다.
• 만약 시스템이 초당 10만명의 고객을 처리해야 한다는 요구가 있다면, 이를 허용할 수 있는 형태로 아키텍처를 구조화해야 함
• 시스템의 처리 요소를 일련의 작은 서비스들로 배열하는 등의 결정은 열어두어야 하는 선택사항 중 하나임

 

개발

• 아키텍처는 개발환경을 지원하는 데 있어 핵심적인 역할을 수행하는데, 콘웨이 법칙이 작용하는 지점이 바로 여기다.
  • 콘웨이의 법칙 : 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
• 많은 팀으로 구성된 조직에서 개발해야 할 때, 각 팀이 독립적으로 행동하기 편한 아키텍처를 반드시 확보하여 개발 동안 팀들이 서로를 방해하지 않아야 한다.
• 이러한 아키텍처를 만들려면 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

 

배포

• 좋은 아키텍처라면 시스템이 빌드된 후 즉각 배포할 수 있도록 지원해야한다.
• 이러한 아키텍처를 만들려면 시스템을 컴포넌트 단위로 적절하게 분할하고 격리시켜야 함

 

중복

• 개발자들은 중복된 코드를 좋아하지 않는다. 코드가 진짜로 중복되었다면, 중복을 줄이거나 제거해야 한다.
• 하지만 중복에도 여러 종류가 있다.
  • 진짜 중복 : 한 인스턴스가 벼경되면, 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용해야함
  • 거짓 또는 우발적인 중복 : 중복으로 보이는 두 코드가 각자의 경로로 발전할 때 다른 이유로 변경되는 것
• 각 유스케이스에서 중복되는 로직이 있더라도, 시간이 지나면서 다른 방향으로 분기하며, 결국 매우 다른 모습을 가질 가능성이 높다.
• 따라서 자동반사적으로 중복을 제거하는 유혹에 빠지지말고, 중복이 진짜 중복인지 확인하라.

 

결론

• 좋은 아키텍처는 시스템이 모노로틱 구조로 태어나서 단일 파일로 배포되더라도, 이후에는 독립적으로 배포 가능한 단위들의 집합으로 성장하고, 또 독립적인 서비스나 마이크로서비스 수준까지 성장할 수 있도록 만들어져야한다.
• 또한 나중에 상황이 바뀌었을 때, 이 진행 방향을 거꾸로 돌려 원래 형태인 모노티릭 구조로 되돌릴 수도 있어야 한다.
• 물론 쉬운일이 아니겠지만, 저자가 말하는 것은 이러한 변경을 예측하여 반영할 수 있도록 만들어야 한다는 점임

 

 

17장. 선긋기

---

• 경계(boundary)는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 만든다.
• 선 일부는 프로젝트 수명 중 아주 초기에, 심지어 코드가 작성되기도 전에 그어지며 어떤 선은 매우 나중에 그려진다.
• 초기에 그어지는 선들은 오랫동안 결정을 연기시켜 결정이 핵심적인 업무 로직을 오염시키지 못하게 만드려는 목적으로 쓰임
• 아키텍처의 목표는 시스템을 유지하는 데 드는 인적 자원을 최소화하는 것인데, 이를 떨어트리는 요인은 결합이다.
• 특히 이른 시점의 결정에 따른 결합인데, 이른 결정은 시스템의 업무 요구사항(유스케이스)과 아무런 관련 없는 결정임

 

플러그인 아키텍처

• 이 설계에서 사용자 인터페이스와 데이터베이스는 플러그인 형태로 고려되었기에 수많은 종류의 사용자 인터페이스와 데이터베이스를 플러그인 형태로 연결하고 대체할 수 있음
  • 웹 기반, 클라이언트/서버 기반, SOA나 콘솔 기반, 또는 임의의 어떤 사용자 인터페이스 기술
  • RDB, NoSQL, 파일 시스템 기반 DB, 임의의 어떤 종류의 DB
• 기술 교체 작업은 사소한 일이 아니지만, 플러그인 구조를 가정한 채 시작함으로써, 변경 작업을 현실성 있도록 만들 수 있다.

 

결론

• 소프트웨어 아키텍처에서 경계선을 그리려면 먼저 시스템을 컴포넌트 단위로 분할해야함
• 일부는 핵심 업무 규칙에 해당하고 나머지 컴포넌트는 플러그인으로, 핵심업무와 직접적인 관련이 없지만 필수 기능을 포함함
• 그 다음 컴포넌트 사이의 화살표가 핵심 업무 방향으로 향하도록 컴포넌트의 소스를 배치함
• 의존성 화살표는 저수준 세부사항에서 고수준의 추상화를 향하도록 배치된다.(의존성 역전 원칙과 안정된 추상화 원칙)

 

 

19장. 정책과 수준

---

• 소프트웨어 시스템이란 정책을 기술한 것이며, 하나의 정책은 이 정책을 서술하는 여러 개의 조그만 정책들로 쪼갤 수 있다.
• 소프트웨어 아키텍처를 개발하는 기술에는 이러한 정책을 신중하게 분리하고, 정책이 변경되는 양상에 따라 정책을 재편성하는 일도 포함된다.
  • 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야함
  • 서로 다른 이유로, 혹은 다른 시점에 변경되는 정책은 다른 수준에 위치하며, 반드시 다른 컴포넌트로 분리해야 한다.
• 좋은 아키텍처라면 각 컴포넌트를 연결할 때, 저수준 컴포넌트가 고수준 컴포넌트에 의존하도록 설계되어야 한다.

 

수준

• 수준(level)을 엄밀하게 정의하자면 ‘입력과 출력까지의 거리’다.
  • 시스템의 입력과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다.
  • 입력과 출력을 다루는 정책이라면 시스템에서 최하위 수준에 위치한다.
• 정책을 컴포넌트로 묶는 기준은 정책이 변경되는 방식에 달려있다.
  • SRP와 CCP에 따르면 동일한 이유로 동일한 시점에 변경되는 정책은 함께 묶임
  • 고수준 정책, 입력과 출력에서 멀리 떨어진 정책은 저수준 정책에 비해 덜 빈번히 변경되고, 보다 중요한 이유로 변경되는 경향이 있음
  • 저수준 정책, 입력과 출력에 가까이 위치한 정책은 덜 빈번하게 변경되며, 덜 중요한 이유로 변경되는 경향이 있음
• 모든 소스 코드 의존성의 방향이 고수준 정책을 향할 수 있도록 정책을 분리했다면 변경의 영향도를 줄일 수 있다.
• 시스템의 최저 수준에서 긴급한 변경이 발생해도, 고수준에 미치는 영향은 거의 없게 된다.

 

 

20장. 업무 규칙

---

• 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차이며, 컴퓨터상으로 구현했는지와 상관없음
• 규칙을 자동화하는 시스템이 없더라도, 사업 자체에 핵심적이며 존재하는 규칙을 핵심 업무 규칙이라고 한다.
• 핵심 업무 규칙이 요구하는 데이터를 핵심 업무 데이터라고 부른다.
• 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기에 객체로 만들 좋은 후보가 되는데, 이를 엔티티라고 부름

 

엔티티

• 엔티티는 컴퓨터 시스템 내부 객체로서, 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구체화 한다.
• 엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있다.
• 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수로들로 구성됨

 

• 예를들어 아래의 Loan 엔티티는 3가지 핵심 업무 데이터를 포함하며, 3가지 핵심 업무 규칙을 인터페이스로 제공한다.

• 이 클래스는 업무의 대표자로서 독립적으로 존재하는데, 순전히 업무에 대한 것이며 이외의 것은 없음
• 이 클래스는 데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 절대 안 된다.

엔티티를 만드는데 꼭 객체 지향 언어를 사용할 필요는 없다.
중요한 것은 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야한다는 것이다.

 

유스케이스

• 유스케이스는 자동화된 시스템이 사용되는 방법을 설명한다.
• 엔티티 내의 핵심 업무 규칙과는 반대로, 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명한다.

• 유스케이스는 엔티티 내부의 핵심 업무 규칙을 언제, 어떻게 호출 할지를 명시하는 규칙을 담는다.
• 유스케이스는 사용자 인터페이스를 기술하지 않으며 시스템이 사용자에게 어떻게 보이는지 설명하지 않는다.
• 유스케이스는 객체로서 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공한다.
• 또한 입/출력 데이터, 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함한다.
• 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못하며, 이는 의존성 역전 원칙을 준수하는 의존성 방향이다.
  • 엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무것도 알지 못함
  • 반대로 저수준인 유스케이스는 고수준의 엔티티를 알고 있음
  • 유스케이스는 단일 애플리케이션에 특화되어 있고, 따라서 해당 시스템의 입력과 출력에 보다 가깝게 위치하기 때문에 저수준임
  • 엔티티는 수많은 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것으로 입력과 출력에 더 멀리 떨어져 있어 고수준임
  • 유스케이스는 엔티티에 의존하는 반면, 엔티티는 유스케이스에 의존하지 않는다.

 

요청 및 응답 모델

• 유스케이스는 입력 데이터를 받아서 출력 데이터를 생성하지만, 이 데이터가 다른 컴포넌트와 주고 받는 방식에 대해서는 몰라야 한다.
• 유스케이스 클래스의 코드가 HTML이나 SQL에 대해 알아서는 안되며 웹과 그 어떤 사용자 인터페이스에도 종속되면 안된다.
• 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합되어 버린다.
• 엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유함으로 엔티티의 참조를 요청/응답 구조에 포함하려는 유혹을 받을 수 있지만, 두 객체의 목적은 완전히 다르다.
• 시간이 지나면 두 객체는 완전히 다른 이유로 변경될 것이고, 두 객체를 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙에 위배된다.

 

결론

• 업무 규칙은 소프트웨어 시스템이 존재하는 이유이자 핵심적인 기능이다.
• 업무 규칙은 사용자 인터페이스나 데이터베이스 같은 저수준의 관심사로 인해 오염되서는 안된다.
• 업무 규칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야하고, 덜 중요한 코드는 플러그인이 되어야한다.
• 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.

 

 

21장. 소리치는 아키텍처

---

아키텍처의 테마

• 소프트웨어 애플리케이션의 아키텍처는 유스케이스에 대해 소리쳐야 한다.
• 아키텍처는 프레임워크에 대한 것이 아니며 아키텍처를 프레임워크로부터 제공받아서는 절대 안된다.
• 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야할 대상이 아님
• 아키텍처를 프레임워크 중심으로 만들면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없음

 

아키텍처의 목적

• 좋은 아키텍처는 유스케이스가 중심이므로, 프레임워크나 도구 등에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 가짐
• 좋은 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 여타 개발 환경 문제나 도구에 대한 결정을 미룰 수 있도록 함
• 좋은 아키텍처는 프로젝트의 훨씬 후반까지 결정을 하지 않아도 되도록 도와줄 뿐만 아니라 결정을 쉽게 번복할 수 있도록 함
• 좋은 아키텍처는 유스케이스에 중점을 두며, 지엽적인 관심사에 대한 결합은 분리시킴

 

하지만 웹은?

• 애플리케이션이 웹을 통해 전달되는 사실은 세부사항이며, 시스템 구조를 지배해서는 절대 안 된다.
• 시스템 아키텍처는 시스템이 어떻게 전달될지에 대해 아무것도 몰라야 한다.
• 아키텍처를 수정하지 않더라도 시스템을 많은 인터페이스로 전달할 수 있어야 함

 

테스트하기 쉬운 아키텍처

• 아키텍처가 유스케이스를 최우선으로 한다면, 프레임워크 없이도 필요한 유스케이스 전부를 단위 테스트 할 수 있어야 한다.
• 테스트를 돌리는데 웹 서버가 반드시 필요한 상황이 되면 안 된다.
• 엔티티 객체는 반드시 POJO여야 하며, 프레임워크나 데이터베이스 및 다른 것들에 의존해서는 안된다.
• 유스케이스 객체가 엔티티 객체를 조작해야 한다.
• 최종적으로, 프레임워크로 인한 어려움을 겪지 않고도 반드시 있는 그대로 테스트할 수 있어야 한다.

 

결론

• 아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안 된다.
• 헬스 케어 시스템을 구축한다면, 새로들어온 프로그래머가 소스 저장소를 봤을 때, 헬스 케어 시스템인지 알아야 한다.
• 새로 합류한 프로그래머는 시스템이 어떻게 전달될지 알지 못하는 상태에서도 모든 유스케이스를 이해할 수 있어야함

 

---

모든 내용은 [클린 아키텍처] 서적의 정리한 내용이며, 망나니 개발자님의 블로그에서 정리 방법을 참고했습니다.

클린 아키텍처: 소프트웨어 구조와 설계의 원칙 | 로버트 C. 마틴 - 교보문고

[개발서적] 클린 아키텍처 4부 컴포넌트 원칙 - 내용 정리 및 요약