독서(Reading)/클린아키텍처(Clean Architecture)5

• 5부 아키텍처 20장 업무 규칙 1. 들어가며 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 핵심 업무 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 존재하는 업무 규칙 핵심 업무 데이터는 시스템이 자동화되지 않은 경우에도 존재하는 데이터 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 됨 해당 유형의 객체를 엔티티라고 함 2. 엔티티 엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체함 엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있음 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성됨 업.. 독서(Reading)/클린아키텍처(Clean Architecture) 2022. 12. 30.

• 5부 아키텍처 19장 정책과 수준 1. 들어가며 소프트웨어 시스템이란 정책을 기술한 것 대다수 주요 시스템에서 하나의 정책은 이 정책을 서술하는 여러 개의 조그만 정책들로 쪼갤 수 있음 소프트웨어 아키텍처를 개발하는 기술에는 정책을 신중하게 분리하고, 정책이 변경되는 양상에 따라 정책을 재편성하는 일도 포함됨 동일한 이유로 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며, 동일한 컴포넌트에 속해야 함 아키텍처 개발은 재편성된 컴포넌트들을 비순환 방향 그래프로 구성하는 기술을 포함 의존성 소스 코드, 컴파일 타임의 의존성이며, java의 경우 Import 구문에 해당함 컴파일러가 잘 동작하기 위해서 필요함 좋은 아키텍처라면 각 컴포넌트를 연결할 때 의존성의 방향이 컴포넌트의 수준을 기반으로 연결되도록 만들어야 함, 즉 저수준 컴포넌트.. 독서(Reading)/클린아키텍처(Clean Architecture) 2022. 12. 30.

• 5부 아키텍처 18장 경계 해부학 1. 들어가며 시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의됨 2. 경계 횡단하기 ‘런타임에 경계를 횡단한다’ : 경계 한쪽에 있는 기능에서 반대편 기능을 호출하여 데이터를 전달하는 일 소스 코드 의존성 관리를 통해 경계를 횡단하게 함 소스 코드 모듈 하나가 변경되면, 이에 의존하는 다른 소스 코드 모듈도 변경하거나, 재컴파일해서 배포해야 할 수 있음 경계는 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단 3. 두려운 단일체 소스 수준 분리 모드 물리적으로 엄격하게 구분되지 않는 형태 함수와 데이터가 단일 프로세서에서 같은 주소 공간을 공유하며 나름의 규칙에 따라 분리되어 있음 단일체(monolith)라고 불리는 단일 실행 파일 배포 관점에서 볼 때 .. 독서(Reading)/클린아키텍처(Clean Architecture) 2022. 12. 30.

• 5부 아키텍처 17장 경계: 선 긋기 1. 들어가며 소프트웨어 아키텍처는 선(경계)을 긋는 기술 경계는 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막음 * 초기에 그어지는 선들은 가능한 한 오랫동안 결정을 연기시키기 위해, 그래서 이들 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰임 이른 결정 시스템의 업무 요구사항, 즉 유스케이스와 아무런 관련이 없는 결정 프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등 좋은 아키텍처 결정이 부수적이며, 결정을 연기할 수 있는 아키텍처 결정을 가능한 한 최후의 순간에 내릴 수 있게 해주며, 결정에 따른 영향이 크지 않게 만듦 2. 두 가지 슬픈 이야기(실패 사례- 이른 결정) P사 모노리틱 데스.. 독서(Reading)/클린아키텍처(Clean Architecture) 2022. 12. 29.

• 5부 아키텍처 16장 독립성 1. 유스케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 함 아키텍트의 최우선 관심사는 유스케이스이며, 아키텍처에서도 유스케이스가 최우선, 아키텍처는 반드시 유스케이스를 지원해야 함 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러나야 함 행위는 일급 요소이며 시스템의 최상위 수준에서 알아볼 수 있으므로 개발자가 일일이 찾아 헤매지 않아도 됨 클래스, 함수 또는 모듈로서 아키텍처 내에서 핵심적인 자리를 차지할 뿐만 아니라, 자신의 기능을 분명하게 설명하는 이름을 가짐 참고 21장 소리치는 아키텍처 2. 운영 요구와 관련된 각 유스케이스에 걸맞은 처리량과 응답시간을 보장해야하며 운영 작업을 허용할 수 있는 형태로 아키텍처를 구조화 해야함 아키텍처에서 각 컴포넌트를 적절히 격리하여 유지하고 컴포넌트.. 독서(Reading)/클린아키텍처(Clean Architecture) 2022. 12. 29.