클린 아키텍처 #5

 

2022.01.07 - [Study/컴퓨터 공학] - 클린 아키텍처

2022.01.11 - [Study/컴퓨터 공학] - 클린 아키텍처 #2

2022.01.18 - [Study/컴퓨터 공학] - 클린 아키텍처 #3

2022.02.15 - [Study/컴퓨터 공학] - 클린 아키텍처 #4

2022.05.16 - [Study/컴퓨터 공학] - 클린 아키텍처 #6

클린 아키텍처 : 5부 16장까지

---

저자 : 로버트 C. 마틴
출판 : 인사이트
출간 : 2019.08.20.

학습 방법 : 책을 읽고 소제목 단위로 핵심 내용을 1~3문장 정도로 요약

---

5부

15장 아키텍처란?

✓ 소프트웨어 아키텍트는 코드와 동떨어져서는 안된다.
✓ 소프트웨어 시스템의 아키텍처란 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이며, 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다.
✓ 아키텍처의 궁극적인 목표는 시스템 수명과 관련된 비용은 최소화 하고 프로그래머의 생산성은 최대화 하는 것

⦿ 개발

✓ 시스템 아키텍처는 개발팀(들)이 시스템을 쉽게 개발할 수 있도록 뒷받침해야만 한다.

⦿ 배포

✓ 소프트웨어 아키텍처는 시스템을 단 한 번에 쉽게 배포할 수 있도록 만드는 데 그 목표를 두어야 한다.

⦿ 운영

✓ 좋은 소프트웨어 아키텍처는 시스템을 운영하는 데 필요한 요구도 알려준다.

⦿ 유지보수

✓ 신중하게 아키텍처를 만들어 시스템을 컴포넌트로 분리하고 안정된 인터페이스를 두어 서로 격리한다면 미래에 추가될 기능에 대한 길을 밝혀둘 수 있을 뿐만 아니라 의도치 않은 장애가 발생할 위험을 크게 줄일 수 있다.

⦿ 선택사항 열어두기

✓ 소프트웨어를 부드럽게 유지하는 방법은 선택사항을 가능한 한 많이, 그리고 가능한 한 오래 열어두는 것이다.
✓ 선택사항이란 중요치 않은 세부사항이다.
✓ 아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책과 무관하게 만들 수 있는 형태의 시스템을 구축하는 것이다.

⦿ 장치 독립성

✓ 프로그램은 운영체제의 서비스를 호출하고 해당 서비스가 추상화된 단위 레코드 장치를 처리한다. 그리고 오퍼레이터가 해당 추상 서비스를 어느 장치에 연결해야 하는지 운영체제에 알려준다.

⦿ 광고 우편

✓ 이름과 주소 레코드에 대한 서식은 정책으로, 세부사항은 장치로 분리하여 어떤 장치를 사용할지에 대한 결정을 연기한 사례

⦿ 물리적 주소 할당

✓ 시스템에서 고수준의 정책이 디스크의 물리적 구조로부터 독립되도록 하여 디스크 드라이브 구조에 대한 결정사항을 애플리케이션으로부터 분리

⦿ 결론

✓ 좋은 아키텍트는 세부사항에 대한 결정을 가능한 한 오랫동안 미룰 수 있는 방향으로 정책을 설계한다.

16장 독립성

⦿ 전제

✓ 좋은 아키텍처는 다음을 지원해야 한다.
- 시스템의 유스케이스
- 시스템의 운영
- 시스템의 개발
- 시스템의 배포

⦿ 유스케이스

✓ 시스템의 아키텍처는 시스템의 의도를 지원해야 한다.
✓ 좋은 아키텍처는 행위를 지원하기 위해 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아볼 수 있게 만들어야 한다.

⦿ 운영

✓ 아키텍처는 요구와 관련된 유스케이스에 걸맞게 아키텍처를 구조화 해야한다.
✓ 이러한 구조화 역시 열어두어야 하는 선택사항 중 하나다.
✓ 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트 간 통신 방식을 특정 형태로 제한하지 않아야 한다.

⦿ 개발

✓ 아키텍처는 개발환경을 지원하는 데 있어 핵심적인 역할을 수행한다.
✓ 콘웨이(Conway)의 법칙: 시스템을 설계하는 조직이라면 어디든지 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들어 낼 것이다.
✓ 잘 격리되어 독립적으로 개발 가능한 컴포넌트 단위로 시스템을 분할할 수 있어야 한다.

⦿ 배포

✓ “즉각적인 배포”라는 목표를 위하여 아키텍처는 배포 용이성을 결정하는데 중요한 역할을 한다.
✓ 이러한 아키텍처를 만들기 위해 시스템을 컴포넌트 단위로 적절하게 분할하고 격리시켜야 한다.

⦿ 선택사항 열어놓기

✓ 좋은 아키텍처는 컴포넌트 구조와 관련된 관심사들 사이에서 균형을 맞추고, 각 관심사 모두를 만족시킨다.
✓ 좋은 아키텍처는 선택사항을 열어 둠으로써, 향후 시스템에 변경이 필요할 때 어떤 방향으로든 쉽게 변경할 수 있도록 한다.

⦿ 계층 결합 분리

✓ UI, 애플리케이션에 특화된 업무 규칙, 애플리케이션과는 독립적인 업무 규칙, 데이터베이스 등은 서로 결합되지 않도록 수평적인 계층으로 분리한다.

⦿ 유스케이스 결합 분리

✓ 유스케이스 그 자체는 서로 다른 이유로 변경된다.
✓ 유스케이스는 수직적으로 각 계층에서 서로 겹치지 않게 한다.
✓ 이와 같이 분리를 하게 되면 기존 요소에 지장을 주지 않고 유스케이스를 추가할 수 있게 된다.

⦿ 결합 분리 모드

✓ 컴포넌트를 서비스 수준까지도 분리해야 한다.
✓ 좋은 아키텍처는 선택권을 열어둔다.

⦿ 개발 독립성

✓ 컴포넌트, 유스케이스가 분리되면 각각의 개발팀은 다른 팀의 간섭을 받지 않고 독립적으로 개발할 수 있다.

⦿ 배포 독립성

✓ 유스케이스와 계층 결합이 분리되면 배포 측면에서도 고도의 유연성이 생겨 운영 중인 시스템에서도 계층과 유스케이스를 교체할 수 있다.

⦿ 중복

✓ 진짜 중복 : 한 인스턴스에서 변경이 생기면 동일한 변경을 그 인스턴스의 모든 복사본에 반드시 적용해야 하는 경우. 제거해야 하는 대상이다.
✓ 거짓된(우발적인) 중복 : 중복으로 보이는 두 코드 영역이 각자의 경로로 발전하는 경우
✓ 중복을 제거하는 경우 진짜 중복과 우발적인 중복을 구분해야 한다.

⦿ 결합 분리 모드(다시)

✓ 소스 수준 분리 모드 : 소스 코드 모듈 사이의 의존성을 제어
✓ 배포 수준 분리 모드 : jar, DLL, 공유 라이브러리와 같이 배포 가능한 단위들 사이의 의존성을 제어
✓ 서비스 수준 분리 모드 : 의존하는 수준을 데이터 구조 단위까지 낮출 수 있고, 순전히 네트워크 패킷을 통해서만 통신하도록 만들 수 있다.
✓ 좋은 아키텍처는 어떤 수준이든 적합한 모드를 선택해 사용할 수 있게 만들어준다.

⦿ 결론

✓ 시스템의 결합 분리 모드는 시간이 지나면서 바뀌기 쉬우며, 뛰어난 아키텍트라면 이러한 변경을 예측하여 큰 무리 없이 반영할 수 있도록 만들어야 한다.