삶은달걀노른자

■ 34장 빠져 있는 장 The Missing Chapter ** 이번 장은 저자가 아닌 다른 사람이 적은 글이다. (By Simon Brown) ​ 악마는 항상 디테일(세부사항)에 있는 법이다. 클린 아키텍처가 물론 도움이 되겠지만 마지막 고비에 걸려 넘어지지 않도록 설계나 코드 조직화와 관련된 몇 가지 추가적인 접근법을 살펴본다. 이 장의 내용은 책의 저자(Robert C. Martin)와 일부 다른 견해도 포함된다. ​ 요약하면, 가능한 한 선택사항을 열어두되 실용주의적으로 행하고, 팀의 규모, 기술 수준, 해결책의 복잡성을 일정과 예산이라는 제약과 동시에 고려하라는 것. 또 선택된 아키텍처 스타일을 강제하는 데 컴파일러의 도움을 받을 수 있을지 고민하며, 데이터 모델과 같은 다른 영역에 결합되지 ..

■ 33장 사례 연구: 비디오 판매 Case Study: Video Sales ​ 웹사이트에서 비디오를 판매하는 소프트웨어 사례를 적용해 보자. 아래는 유스케이스를 분석한 것이다. 액터는 4개인데, 단일 책임 원칙에 따라 신규 기능의 추가나 기존 기능의 변경은 반드시 이 4개의 액터에게 기능을 제공하기 위해서여야 한다. 아래는 초기 컴포넌트 아키텍처의 모습이다. 각 경계를 구분으로 뷰, 프레젠터, 인터렉터, 컨트롤러가 나눠져 있는 전형적인 모습니다. 각 컴포넌트는 jar나 dll에 해당하지만, 뷰와 프레젠터를 합쳐서 같은 jar에 두고 나머지는 각각의 jar로 만들거나 나머지를 하나의 jar로 합치는 방법도 가능하다. ​ 이처럼 선택지를 열어두면(컴포넌트를 독립적으로 컴파일/빌드 할 수 있는 환경으로 구..

■ 32장 프레임워크는 세부사항이다 Frameworks Are Details ​ 프레임워크 역시 세부사항이다. 우리가 잘 아는 Spring 같은 프레임워크가 그렇다. 따라서 프레임워크는 아키텍처가 아니며 업무규칙으로부터 떨어져야 한다. 아키텍처 바깥쪽 원에 속하는 세부사항으로 취급하고 안으로 못 들어오게 해야 한다. ​ 물론 이것은 현실적이지 않을 수 있다. 사실상 규모가 있는 대부분의 프로젝트에서는 당연히 어떤 형태로든지 프레임워크를 쓰고 있으며 아마 저자가 당부하는 아키텍처 원칙을 적용하지 않을 것이기 때문이다. ​ 저자는 이에 대한 해결책으로, 가령 업무 객체를 만들 때 프레임워크가 자신의 기반 클래스로부터 파생하기를 요구하면, Proxy를 만들고 업무규칙에 플러그인할 수 있는 컴포넌트를 Proxy..

■ 31장 웹은 세부사항이다 The Web Is a Detail ​ 웹은 GUI 이므로 아키텍처에서 업무로직과 분리되어야 하는 세부사항이다. ​ 물론 웹은 너무 특이해서 장치 독립적인 아키텍처를 추구하는 것이 어렵다는 것을 저자도 어느정도 인정은 한다. 다만 UI와 어플리케이션 사이에 존재하는 또다른 추상화 경계인 유스케이스가 어느정도 완충작용을 할 수 있으리라 본다. ​ ​

◆ Part 6 세부사항 Details ​ ■ 30장 데이터베이스는 세부사항이다 The Database Is a Detail ​ 이 책에서 일관되게 표현하고 주장하는 것 중 하나는 바로 정책과 세부사항이라는 개념이다. 정책은 시스템의 업무 로직을 말하고, 세부사항은 이를 지원하는 도구 정도로 인식하면 된다. ​ 이러한 관점에서 데이터베이스는 세부사항에 속한다. 데이터 구조과 모델은 아키텍처에서 중요한 요소가 맞지만 데이터베이스는 아니다. (여기서 말하는 데이터베이스는 주로 RDBMS를 지칭하는 듯 보인다) ​ 데이터베이스가 발전하게 된 이유는 데이터를 디스크에 저장하면서 속도 저하를 만회하기 위한 색인, 캐시, 쿼리 플랜 최적화가 필요했기 때문이다. 하지만 이렇게 가져온 데이터는 결국 RAM으로 올라오게..

■ 28장 테스트 경계 The Test Boundary ​ 테스트는 아키텍처 원에서 가장 바깥쪽을 생각할 수 있다. 내부의 어떤 것도 테스트에 의존하지 않으며 반대로 테스트는 내부 컴포넌트를 향해 항상 원의 안쪽으로 의존한다. 잘 깨지지 않는 테스트를 만들기 위해서는 당연히 테스트를 고려해서 설계해야 한다. 즉, 변동성이 있는 것에 의존하지 말아야 한다. 가령 업무규칙은 GUI를 사용하지 않고 테스트할 수 있어야 한다. ​ 당연한 말이지만 업무규칙들 검증하기 위한 테스트용 API를 만들어서 테스트를(테스트 구조를) 어플리케이션으로부터(어플리케이션 구조로부터) 분리해야 한다. ​ ​

■ 27장 '크고 작은 모든' 서비스들 Services: Great and Small ​ 서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 아키텍처적으로는 크게 중요하지 않다. 아키텍처는 경계를 넘나드는 의존성에 의해 정의되는데, 서비스는 구성요소가 통신하는 함수 호출에 지나지 않는다. ​ 아키텍처의 경계는 서비스 사이에 있지 않고 서비스를 관통하며 서비스를 컴포넌트 단위로 분할한다. 아키텍처 경계를 정의하는 것은 서비스 내에 위치한 컴포넌트다. ​ 책에서 말하는 횡단 관심사는 여러 서비스를 횡으로 나열했을 때(1111 처럼 옆으로) 이 서비스들을 횡으로 관통(---> 로)할 수밖에 없는 아키텍처 경계나 나올 수 있으며, 이를 처리하려면 서비스 내부도 의존성 규칙을 준수하는 컴포넌트 아키텍처로..

■ 26장 메인 컴포넌트 The Main Component ​ 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다. 운영체제만이 메인에 의존한다. ​ 메인은 초기 조건과 설정을 구성하고 외부자원을 모두 수집한 후, 제어권을 어플리케이션의 고수준 정채으로 넘기는 플러그인이라고 생각하면 된다. 아키텍처 경계 바깥에 위치한다고 보면 설정 관련 문제를 쉽게 해결할 수 있다. ​ ​ ​

■ 25장 계층과 경계 Layers and Boundaries ​ 아키텍처 경계는 어디에나 존재한다. 아키텍트는 이 경계가 무엇이고 언제 필요하며 구현 가능여부(비용 대비)를 신중하게 결정해야 한다. 프로젝트 초반에는 알기 어렵지만 시스템이 발전함에 따라 주의를 기울여야 한다. (아키텍처 경계에 대한 글은 17장에서 볼 수 있다) ​ 아키텍처 경계를 찾아가는 예는 아래 그림의 흐름에서 볼 수 있다. (게임 어플리케이션의 예) ​ 1. 언어 및 데이터 저장소에 무관한 게임 규칙 적용 ​ 2. 텍스트 메커니즘 확장 및 추상 컴포넌트 추가 ​ 3. 네트워크 컴포넌트를 추가하여 단순화한 다이어그램 ​ 4. 게임 정책을 상위 수준과 하위 수준으로 분리 ​ 5. 마이크로서비스 API 추가 : MoveManageme..

■ 24장 부분적 경계 Partial Boundaries ​ 완벽한 아키텍처 경계를 만드는 것은 많은 비용과 노력이 드는 일이므로 부분적인 경계를 생각해 볼 수도 있다. 독립적인 컴포넌트를 만들되 그냥 하나의 컴포넌트 안에 그대로 모아 놓는 것이다. 물론 부분적 경계를 만들려면 완벽한 경계를 만들 때만큼의 코드량과 사전 설계가 필요하지만 다수의 컴포넌트 관리에 대한 부담은 없다. ​ 부분적 경계를 구현하는 방법은 ​ 1. 컴포넌트를 분리해서 설계하되 실제로는 하나가 되도록 만들기 (다운로드 시 한 개만 다운로드) 2. Strategy 패턴을 사용하기 (패턴을 잘 몰라서 이 부분은 자세하게 모르겠다) 3. Facade 패턴을 사용하기 (상동) ​ ​