SEARCH : 📚 Book/Clean Architecture(28)

CATEGORY : 📚 Book/Clean Architecture(28)

TAGS : 📚 Book/Clean Architecture(28)

ARCHIVE : 📚 Book/Clean Architecture(28)

34장 빠져 있는 장

34장 빠져 있는 장

2020. 2. 22.

들어가며 온라인서점시스템에서 고객이 주문 상태를 조회할 수 있어야한다는 유스케이스를 통해 클린아키텍처는 잠시 제쳐놓고 설계나 코드 조직화와 관련된 몇가지 접근법을 살펴봄. 계층 기반 패키지 단순한 설계방식으로 수평 계층형 아키텍처가있음. 기술적인 관점에서 해당코드가 하는일(service, repository 등)에 기반해서 그 코드를 계층으로 분할하는것을 계층기반 패키지라 부름. 이러한 계층형 아키텍처는 복잡함을 겪지않고 무언가를 작동시켜주지만 업무 도메인에 대해 아무것도 말해주지 않음. → 전혀다른 업무도메인이라도 코드를 계층형 아케턱쳐로 만들어 나란히 놓고보면 웹, 서비스, 레파지토리로 구성된 모습이 비슷하게 보이기 때문 기능 기반 패키지 서로 연관된 기능, 도메인 개념, 또는 Aggregate Ro..
33장 사례 연구: 비디오 판매

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

2020. 2. 22.

제품 아키텍처를 적용해볼 사례로 소프트웨어 튜토리얼 비디오를 판매하는 "소프트웨어 제품" 시스템의 초기 아키텍처를 결정짓는 첫 단계는 액터와 유스케이스를 식별하는것임. 유스케이스 분석 액터의 관점에서 책임을 정의할 수 있는 단일책임 원칙에 따르면 네 액터가 시스템이 변경되어야 할 네 가지 주요 근원이 됨. 특정 액터의 변경이 나머지 액터에게는 전혀 영향을 미치지 않게 해야함. 중앙 점섬으로된 유스케이스는 추상유스케이스임. 이는 범용적인 정책을 담고있으며 다른 유스케이스에서 이를 더 구체화시킴. 시청자, 구매자입장에서 카탈로그 조회하기는 추상 카탈로그 조회하기 유스케이스를 상속함. → 추상 유스케이스는 저자만의 방법임, UML 스테레오타입을 사용해도 무난. 컴포넌트 아키텍처 유스케이스 식별 후 예비단계 컴..

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

2020. 2. 22.

프레임워크 제작자 대다수의 프레임워크 제작자는 프레임워크 사용자가 풀어야 할 특별한 관심사를 염두에 두지 않지만 사용자의 문제와 프레임워크가 풀려는 문제와 꽤 많이 겹침. (그만큼 많이 겹치기에 인기를 많이 끌었으며 겹치는 영역이 클수록 프레임워크는 실제로 더욱 유용해짐.) 혼인 관계의 비대칭성 프레임워크 제작자는 프레임워크사용자의 애플리케이션이 가능하면 프레임워크에 공고하게 결합될 것을 강하게 역설함. 결합되어 생기는 위험요소는 오롯이 사용자가 감수함. 이는 사실상 프레임워크 제작자는 사용자에게 프레임워크와 혼인하기를 요구한다고 볼 수 있으며 사용자는 프레임워크에 대해 장기간 헌신을 하지만 프레임워크 제작자는 그에 상응하는 헌신은 사용자에게 하지 않음. → 제작자는 프레임워크에 대해 절대적인 제어권을 ..

31장 웹은 세부사항이다

2020. 2. 22.

끝없이 반복하는 추 모든 연산능력을 중앙서버에 두는방식, 단말에 두는방식사이에서 끊임없이 진동 해옴. 웹 또한 이런 진동을 겪음. 서버 팜(server farm) → 브라우저에 애플릿 추가 → 동적처리 서버로이동 → 브라우저에 Ajax, Js추가 진동은 그저 핵심 업무 규칙의 중심에서 밀어내고 싶은 단기적인 문제일 뿐이며 이러한 진동은 한동안 계속될 것이라 저자는 말함. 데스크톱 앱으로 개발된 개인용 재무시스템이 출시함. 어느날 웹이 등장하자 마케터는 재무시스템의 GUI를 웹브라우저와 같은 룩앤필을 제공하고자 기획 및 시행. 저자는 그자리에 있었더라면 업무규칙을 GUI로부터 격리시키고자 할것이라고함. 요약 GUI는 세부사항임. 핵심업무 로직에서 분리된 경계 바깥에 두어야하는 입출력장치임.

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

2020. 2. 22.

들어가며 데이터베이스는 엔티티가아닌 데이터에 접근할 방법을 제공해주는 유틸리티이자 저수준의 세부사항임. 관계형 데이터베이스 관계형 데이터베이스의 기술이 얼마나 뛰어나든 그저 기술이며 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처 외부 원 최하위수준의 함수만 알고있어야함. 다시말하지만 그저 저수준의 세부사항이기때문. 데이터베이스 시스템은 왜 이렇게 널리 사용되는가? 그 이유는 '디스크'에 있음. 48인치를 겹겹이 쌓아 겨우 20MB를 담을 수 있었던 디스크가 현재는 지름 3인치의 단일 판이 1TB이상을 저장할 수 있음. 하지만 치명적인 단점으로 느리다라는 특성이 존재함. 디스크 구조상 필요한 바이트를 읽기위해선 밀리초 단위가 걸림, 대다수의 프로세서는 한명령어를 처리하는 주기에 비해 백만배나 오래걸..

28장 테스트 경계

2020. 2. 22.

시스템 컴포넌트인 테스트 아주작은 테스트이든, TDD이든 대규모이든 아키텍처적으로는 관점으로는 모두 동일하게 봄. 테스트의 의존성은 항상 테스트 대상이 되는 코드를 향하기 때문에 가장 바깥쪽 원으로 생각할 수 있음. 테스트는 독립적으로 배포가 가능함. 테스트는 시스템 컴포넌트 중 가장 고립되어 있으며 테스트가 시스템운영에 꼭 필요한것은 아님. → 어떤사용자도 테스트에 의존하지 않기 때문이며 운영이아닌 개발을 지원하기 때문. 테스트를 고려한 설계 테스트는 시스템의 설계 범위 밖에 있지않음. 그러나 시스템에 강하게 결합되어 버린 테스트라면 시스템 컴포넌트가 사소하게 변경하더라도 이와 결합된 수 많은 테스트가 깨질 수 있음. 그러므로 개발자는 시스템을 변경하지 않으려 할것이며 이로인해 시스템은 뻣뻣해질 것임...
27장 '크고 작은 모든' 서비스들

27장 '크고 작은 모든' 서비스들

2020. 2. 22.

서비스 아키텍처 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는 '서비스' 라는 것은 아키텍처 관점에서 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재함. 서비스 아키텍처가 주는 이점들에 대해 저자는 따져 봄. 결합 분리의 오류 시스템을 서비스들로 분리함으로써 서비스 사이의 결합이 확실히 분리된다는 이점이 있음. → 모든 서비스 인터페이스가 잘 정의 되어있으며 서비스는 다른 서비스 변수에 직접 접근할 수 없어야 함. 그러나 서비스 사이를 오가는 데이터 레코드에 새로운 필드를 추가한다면 이 필드를 사용하는 서비스는 모두 변경되어야함. 서비스들은 이 필드에 담긴 데이터를 해석하는 방식을 사전에 완벽하게 조율 해야함. 따라서 서비스들은 데이터 레코드에 강하게 결합되어 서비스들 간에 간접적인 ..
26장 메인(Main) 컴포넌트

26장 메인(Main) 컴포넌트

2020. 2. 22.

들어가며 모든 시스템에는 최소 하나의 컴포넌트가 존재함. 컴포넌트가 나머진 컴포넌트를 생성, 조정, 관리함. 저자는 이 컴포넌트를 메인(Main)이라고 부름. 궁극적인 세부사항 메인 컴포넌트는 궁국적인 세부사항으로 가장 낮은 수준의 정책임. 메인은 클린 아키텍처에서 가장 바깥 원에 위치하는 지저분한 저수준 모듈임. 메인은 고수준의 시스템을 위한 모든것을 로드한 후 제어권을 고수준의 시스템에게 넘김. → 예를들면 책에 내용중인 움퍼스 게임에서도 main 함수에서 게임의 메인 루프, 입력 명령어 해석을 처리하지만 명령어의 실제 처리는 다른 고수준 컴포넌트로 위임시킴. 결론 메인에서 초기 설정을 구성하고 외부 자원 수집 및 제어권을 고수준 정책으로 넘기는 플러그인이라고 생각해야함. 플러그인이므로 애플리케이션별..
25장 계층과 경계

25장 계층과 경계

2020. 2. 22.

움퍼스 사냥게임 다양한 언어로 지원되는 게임이며 게임 규칙은 어떤 언어 UI로 사용 되더라도 의존성을 잘 관리하면 그림과 같이 게임임 규칙을 재사용할 수 있음. 게임상태를 저장하는 컴포넌트가 있더라도 마찬가지로 의존성 관리가 되어 게임 규칙을 의존하는 형태. (당연히 고수준인 규칙을 의존하는 형태) 클린 아키텍처? UI에서 언어가 유일한 변경의 축은 아니기 때문에 변경의 축에 의해 정의 되는 잠재된 아키텍처 경계가 있을 수 있음. 예를 들면 텍스트를 주고받는 메커니즘을 다양하게 만들고 싶을 수 도 있음. 이 모든 경우에 해당 Boundary 인터페이스가 정의하는 API는 의존성 흐름의 상위에 위치한 컴포넌트에 속함. English, SMS 와 같은 변형들을 모두 제거하고 API 컴포넌트만 집중한 단순화된..
24장 부분적 경계

24장 부분적 경계

2020. 2. 22.

들어가며 아키텍처를 완벽히 만드는 데는 당연히 비용이 많이 듦. 애자일 커뮤니티에 속한 사람 중 많은 이는 선행적인 아키텍처 설계를 탐탁치 않게 여김. 하지만 아키텍트는 "어쩌면 필요할지도." 라는 생각이 들 수 도 있기 때문에 만약 그렇다면 부분적 경계를 구현해볼 수 있음. 마지막 단계를 건너뛰기 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것임. 부분적 경계 전략을 기반으로 FitNess는 웹 서버 컴포넌트가 위키나 테스트 영역과는 분리되도록 설계했음. 새로운 웹 기반 애플리케이션을 만들 때 해당 웹 컴포넌트를 재사용할 수도 있다고 생각했기 때문. 그러나 시간이 흐르며, 별도로 분리한 웹 ..