[IT 도서 리뷰] 클린 아키텍처 (6부 세부사항)

책 정보

---

https://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24

 

30장 데이터베이스는 세부사항이다

---

• 관계형 데이터베이스
  • 관계형 테이블은 특정한 형식의 데이터에 접근하는 경우에는 편리
  • 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요치 않음
• 데이터베이스 시스템은 왜 이렇게 널리 사용되는가?
  • '디스크' 때문
  • 디스크의 치명적인 약점 : 느리다
  • 시간 지연을 완화하기 위해 색인, 캐시, 쿼리 계획 최적화가 필요해짐 -> 시간이 지나면서 두 가지 유형으로 분리
    • 파일 시스템과 RDBMS
  • 파일 시스템은 문서 기반
  • 데이터베이스는 내용 기반
• 디스크가 없다면 어떻게 될까?
  • 데이터가 데이터베이스나 파일 시스템에 있더라도, RAM으로 읽은 후에는 다루기 편리한 형태로 그 구조를 변경
  • 이처럼 할 것.
• 세부사항
  • 데이터베이스는 그저 메커니즘에 불과
• 하지만 성능은?
  • 하지만 저수준의 관심사라서 아키텍처와는 관련이 없음
• 개인적인 일화
• 결론
  • 체계화된 데이터 구조와 데이터 모델은 아키텍처적으로 중요
  • 기술과 시스템은 아키텍처적으로 중요치 않음
  • 데이터는 중요하지만 데이터베이스는 세부사항

31장 웹은 세부사항이다

---

• 끝없이 반복하는 추
  • 웹이 있기 전에는 클라이언트-서버 아키텍처
  • 그 전에는 중앙집중식 미니컴퓨터
  • 그 전에는 그린 스크린 단말기가 연결되는 메인프레임
  • 그 전에는 컴퓨터실과 천공카드
  • 연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에서 우리는 끊임없이 움직임
  • 업무 규칙을 UI로부터 분리해야 함
• 요약
  • GUI는 세부사항
  • 웹은 GUI
  • 따라서 핵심 업무 로직에서 분리된 경계 바깥에 두어야 함
  • 웹은 입출력 장치이므로 장치 독립적으로 만들어야 한다는 규칙에서 예외가 될 수 없음
• 결론
  • 추상화는 쉽지않을 것이지만, 가능함

32장 프레임워크는 세부사항이다

---

• 프레임워크 제작자
  • 프레임워크 제작자는 자신이 해결해야 할 고유한 문제나 자신의 동료와 친구들의 문제를 알고 있음
  • 그러한 문제들을 해결하기 위해 프레임워크를 만듦
• 혼인 관계의 비대칭성
  • 프레임워크 제작자는 프레임워크에 공고하게 결합될 것을 강하게 역설
  • 모든 위험과 부담은 우리만 감수
• 위험 요인
  • 프레임워크의 아키텍처는 깔끔하지 않은 경우가 많음
    • 의존성 규칙을 위반하는 경향이 있음
  • 프레임워크는 애플리케이션의 초기 기능을 만드는 데는 도움이 될 것
    • 제품이 성숙해지면서 프레임워크가 제공하는 기능과 틀을 벗어나게 될 것
  • 프레임워크는 도움되지 않는 방향으로 진화할 수도 있음
    • 도움도 되지 않는 신규 버전으로 업그레이드하느라 다른 일을 못할 수도 있음
  • 새롭고 더 나은 프레임워크가 등장해서 갈아타고 싶을 수도 있음
• 해결책
  • 프레임워크와 결혼하지 말라!
  • 사용할 수는 있지만 결합해서는 안 됨 -> 세부사항으로 취급하라
• 이제 선언합니다
  • 결혼해야하는 것도 있음 C++과 STL, 자바와 표준 라이브러리
  • 이러한 관계는 정상이지만 선택적이어야 함
• 결론
  • 프레임워크와의 첫만남부터 결혼하려 들지 말라
  • 연애를 할 수 있는 방법을 확인하라 (연애는 필수 결혼은 선택)

33장 사례 연구: 비디오 판매

---

• 제품
  • 제품 : 웹 사이트에서 비디오를 판매하는 소프트웨어
  • 판매하길 원하는 비디오들이 있고, 그걸 개인과 기업에게 웹을 통해 판매
  • 개인
    • 단품 가격을 지불해 스트리밍으로 보거나, 더 높은 가격을 내고 비디오를 다운로드해서 영구 소장할 수 있음
    • 시청자인 동시에 구매자
  • 기업
    • 스트리밍 전용, 대량 구매를 하면 할인 가능
    • 다른 사람들이 시청할 비디오를 구매하는 사람이 따로 있음
• 유스케이스 분석
  • 4개의 주요 엑터 : 제작자, 구매자, 관리자, 시청자
  • SRP에 따라 분할하여, 특정 액터를 위한 변경이 나머지 액터에게는 전혀 영향을 미치지 않게 만들어야 함
• 컴포넌트 아키텍처
  • 뷰, 프레젠터, 인터랙터, 컨트롤러로 분리
• 의존성 관리
  • 사용 관계는 제어흐름과 같은 방향
  • 상속 관계는 제어흐름과 반대 방향
  • -> 개방 폐쇄 원칙
• 결론
  • 단일 책임 원칙에 기반한 액터의 분리
  • 의존성 규칙
  • 코드를 한번 구조화하고 나면 시스템을 실제로 배포하는 방식은 다양하게 선택할 수 있게 됨

34장 빠져 있는 장

---

• 예제
  • 온라인 서점 구축
  • 고객이 주문 상태를 조회할 수 있어야 한다는 유스케이스를 구현해야 함
• 계층 기반 패키지
  • 가장 단순한 첫 번째 설계 방식은 전통적인 수평 계층형 아키텍처
  • 기술적인 관점에서 해당 코드가 하는 일에 기반해 코드를 분할
  • 웹, '업무 규칙', 영속성 코드를 위해 계층이 각각 하나씩 존재 (유사한 종류의 것들을 묶는 도구로 사용)
    • 자바 예시
    • OrdersController : 웹 컨트롤러, 웹 기반 요청 처리
    • OrdersService : 주문 관련  '업무 규칙' 정의
    • OrdresServiceImpl : OrdersService의 구현체
    • OrdersRepository : 영구 저장된 주문 정보에 접근하는 방법을 정의하는 인터페이스
    • JdbcOrdersReopository : OrdersRepository 인터페이스의 구현체
  • 소프트웨어가 커지고 복잡해지기 시작하면 더 잘게 모듈화해야 할지를 고민
• 기능 기반 패키지
  • 서로 연관된 기능, 도메인 개념, 또는 Aggregate Root에 기반하여 수직으 ㅣ얇은 조각으로 코드를 나누는 방식
• 포트와 어댑터
  • 내부(도메인)과 외부(인프라)로 구성
• 컴포넌트 기반 패키지
  • 대다수가 전통적인 계층적 아키텍처를 기반
  • 컴포넌트 기반 패키지
    • 큰 단위의 단일 컴포넌트와 관련된 모든 책임을 하나의 자바 패키지로 묶는 데 주안점
• 구현 세부사항엔 항상 문제가 있다
  • 자바에선 public 키워드를 지나칠 정도로 사용 -> 캡슐화 관련 이점을 활용하지 않겠다는 뜻
• 조직화 vs. 캡슐화
  • 모든 타입을 public으로 지정 -> 조직화를 위한 메커니즘
• 다른 결합 분리 모드
• 결론: 빠져 있는 조언
  • 선택사항을 열어두되, 실용주의적으로 행하라.