본문 바로가기

분류 전체보기560

[Clean Architecture 정리] 23장. 프레젠터와 험블 객체 23장. 프레젠터와 험블 객체 프레젠터는 험블 객체(Humble Object) 패턴을 따르는 형태로, 아키텍처 경계를 식별하고 보호하는데 도움을 준다. 험블 객체 패턴 험블 객체 패턴은 디자인 패턴으로 테스트하기 어려운 행위와 쉬운 행위를 단위 테스트 시에 쉽게 분리할 수 있도록 고안되었다. 기본적인 아이디어는 행위를 두 개의 모듈로 나누고 기본적인 본질을 남긴 뒤, 테스트하기 어려운 행위를 험블 객체로, 테스트 하기 쉬운 행위는 나머지 모듈로 옮기는 것이다. 프레젠터와 뷰 뷰는 험블 객체이며 테스트하기 어렵다. 뷰는 단순히 데이터를 화면으로 로드할 뿐이다. 프레젠터는 테스트하기 쉬운 객체이다. 프레젠터는 애플리케이션으로부터 전달받은 데이터를 화면에 포맷으로 변환하는 역할을 담당한다. 테스트와 아키텍처 .. 2022. 8. 30.
[Clean Architecture 정리] 22장. 클린 아키텍처 22장. 클린 아키텍처 아키텍처와 관련된 아이디어들의 공통적인 목표는 계층 분리를 통한 관심사 분리(separation of concerns)다. 각 아키텍처는 프레임워크 독립성, 테스트 용이성, UI 독립성, 데이터베이스 독립성, 모든 외부 에이전시에 대한 독립성이라는 공통적인 특징을 가진다. 의존성 규칙 위 그림은 소프트웨어의 영역을 표현한 것으로 원 중앙으로 갈수록 고수준의 소프트웨어를 의미한다. 중요한 것은 의존성 규칙(Dependency Rule)이며, 소스 코드 의존성은 원 안쪽인 고수준을 향해야 한다. 바깥쪽 원은 안쪽 원의 어떠한 것(함수, 클래스, 변수 등)도 몰라야하며 영향을 주지 않아야 한다. 엔티티 엔티티는 가장 일반적이며 고수준의 규칙, 즉 전사적인 핵심 업무 규칙을 캡슐화 한다... 2022. 8. 30.
[Clean Architecture 정리] 21장. 소리치는 아키텍처 21장. 소리치는 아키텍처 아키텍처의 테마 소프트웨어 아키텍처는 시스템의 유스케이스를 지원하는 구조이다. 프레임워크에 대한 것이 아니다. 아키텍처의 목적 좋은 아키텍처는 유스케이스를 중심을 두며 프레임워크, 도구, 환경에 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다. 프레임워크 도구, 환경은 지엽적인 관심사이며 결합을 분리시켜 이들에 대한 결정을 미루고 선택사항을 열어두어야 한다. 하지만 웹은? 웹은 전달 메커니즘이며, 애플리케이션 아키텍처에서도 전달 메커니즘으로 다뤄야한다. 애플리케이션이 웹을 통해 전달된다는 것은 세부사항이지 시스템 구조를 지배해서는 안된다. 프레임워크는 도구일 뿐, 삶의 방식은 아니다. 앞서 말한 것처럼, 좋은 아키텍처는 유스케이스에 중점을 두며, 프.. 2022. 8. 29.
[Clean Architecture 정리] 20장. 업무 규칙 업무 규칙 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차를 의미한다. 업무 규칙 중 사업 자체에 핵심적이며, 자동화된 시스템이 없더라도 존재하는 업무 규칙을 '핵심 업무 규칙(Critical Business Rule)', 핵심 업무 규칙에서 요구하는 데이터를 '핵심 업무 데이터(Critical Business Rule)'이라고 하고, 이 둘은 엔티티(Entity) 객체로 묶을 수 있다. 엔티티 엔티티는 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 일련의 핵심 업무 규칙을 구체화한다. 엔티티 객체는 핵심 업무 데이터를 포함하고, 엔티티의 인터페이스는 핵심 업무 규칙의 구현한 함수로 구성된다. 엔티티는 업무에 관한 것이지 어떤 시스템으로 구성할지, 어떻게 저장할지 등의 .. 2022. 8. 28.
[Clean Architecture 정리] 19장. 정책과 수준 19장. 정책과 수준 소프트웨어 시스템은 정책을 기술이며, 프로그램은 입력이 출력으로 어떻게 변환되는지 그 과정을 정책으로 기술한 것이다. 소프트웨어 아키텍처는 이 정책을 분리하는 역할을 맡는다. 동일한 시점과 이유로 변경되는 정책은 같은 수준, 같은 컴포넌트에 위치해야 한다. 반대로 다른 시점, 이유로 변경되는 정책은 다른 수준, 다른 컴포넌트로 분리되어야 한다. 각 컴포넌트는 서로를 의존하며 소스 코드, 컴파일 타임의 의존성으로 연결된다. 좋은 아키텍처는 이러한 의존성을 컴포넌트 수준에서, 저수준 컴포넌트가 고수준 컴포넌트를 의존하도록 한다. 수준 (level) 수준은 '입력과 출력까지의 거리'를 의미한다. 입력과 출력까지의 거리와 가까울수록 저수준이며, 멀수록 고수준 정책에 해당된다. 데이터를 읽어.. 2022. 8. 25.
[Clean Architecture 정리] 18장. 경계 해부학 18장. 경계 해부학 시스템 아키텍처는 컴포넌트를 분리하는 경계에 의해서 정의되며 경계는 다양한 형태로 존재한다. 경계 횡단하기 소스 코드의 변경은 의존하는 다른 소스 코드에 영향을 주기 때문에 적절히 경계를 횡단하는 방법은 이러한 소스 코드의 의존성을 관리하는 것이다. 경계는 소스 코드의 변경에 의한 영향을 막는 수단으로써 존재한다. 두려운 단일체 다양한 경계 중 가장 단순하고 흔한 형태는 물리적으로 구분되지 않는 단일 실행 파일 형태의 단일체(monolith)이다. 배포 관점에서 단일체의 경계는 드러나지 않지만, *동적 다형성에 의존해 내부 의존성 관리할 수 있다. 정적 다형성(Static Polymorphism)과 동적 다형성(Dynamic Polymorphism) 정적 다형성(Static Poly.. 2022. 8. 23.
[Clean Architecture 정리] 17장. 경계: 선 긋기 경계: 선 긋기 소프트웨어 아키텍처는 시스템 요소를 분리하는 경계를 긋는 기술이며, 이 경계로 인해 경계 한 쪽의 요소가 다른 한쪽의 요소에 대해서 알지 못한다. 경계를 긋는 행위의 목표는 인적 자원에 드는 비용을 최소화하는 것이다. 인적 자원의 비용을 높이는 요인 중 결합(coupling)이 있으며, 특히 너무 이른 결정에 의한 결합이 비용을 높이게 된다. 두 가지 슬픈 이야기 본 잘못된 아키텍처의 사례로 두 회사의 이야기를 다루고 있다. 첫번째는 데스크톱 GUI 애플리케이션을 개발한 P사의 이야기이다. 90년대 후반 웹 어플리케이션이 대세를 이루자 P사는 자사 제품을 웹으로 변환하려는 작업에 착수했다. 이러한 과정에서 P사는 이른 결정을 하게 되었고, 결국 엄청난 개발 비용으로 인한 비극을 맞게 되었.. 2022. 8. 21.
[Clean Architecture 정리] 16장. 독립성 16장. 독립성 좋은 아키텍처가 지원해야하는 것 1. 유스케이스 아키텍처는 시스템의 유스케이스(의도)를 지원해야 한다. 아키텍처는 시스템의 행위를 명확하게 하고 외부로 드러내며 아키텍처 수준에서 시스템의 의도를 파악할 수 있도록 만들어야 한다. 2. 운영 운영 관점에서 아키텍처는 더 실질적인 역할을 맡는데, 각 유스케이스에 맞는 처리량과 응답 시간이다. 특정 시스템에서 비기능적인 요구사항이 있다면, 반드시 이러한 운영작업을 처리할 수 있는 형태로 아키텍처를 구조화해야 한다. 3. 개발 아키텍처는 개발환경과 관련해 핵심적인 역할을 맡으며, 콘웨이 법칙을 적용된다. 각 팀이 독립적으로 개발할 수 있는 형태로 아키텍처를 구성하고, 서로를 방해하지 않도록 해야 한다. 시스템을 설계하는 조직이라면 어디든지 그 조.. 2022. 8. 21.
[Clean Architecture 정리] 15장. 아키텍처 아키텍처 시스템 아키텍처 - 시스템 아키텍처란 '컴포넌트 분할', '컴포넌트 배치', '컴포넌트 간 의사소통' 등 시스템을 구축했던 사람들이 만들어낸 시스템의 형태이다. - 시스템 아키텍처는 소프트웨어의 개발, 배포, 운영, 유지보수가 쉽게 될 수 있도록 설계되어야 한다. - "이러한 일을 용이하게 만들기 위해서는 가능한 한 많은 선택지를, 가능한 한 오래 남겨두는 전략을 따라야 한다." - 아키텍처의 목적은 시스템 생명 주기를 지원하는 것이고, 궁극적인 목표는 시스템 수명과 관련된 비용을 최소화하고, 프로그래머의 생산성은 최대화하는 것이다. 소프트웨어 아키텍트 - 소프트웨어 아키텍트는 프로그래밍 작업을 계속해서 하는 동시에 팀원이 생산성을 극대화할 수 있는 설계를 하도록 방향을 이끌어 줘야한다. - 소.. 2022. 7. 31.
[Clean Architecture 정리] 14장. 컴포넌트 결합 (2) 하향식(top-down) 설계 컴포넌트 의존성 다이어그램은 애플리케이션 기능 기술보다 빌드 가능성(buildability)과 유지 보수성(maintainability)를 보여주는 지도와 같다. 따라서, 컴포넌트 구조는 초기에 설계할 수 없고 시스템이 성장하고 변경될 때 함께 진화하기 때문에 하향식 설계될 수 없다. 안전된 의존성 원칙 (SDP, Stable Dependencies Principle) - "안정성의 방향으로 의존하라" - 설계는 결코 정적일 수 없으며 설계를 유지하다보면 변경은 불가능하다. - 변경이 쉽지 않은 컴포넌트가 변경이 예상되는 컴포넌트에 의존하게 만들면 안된다. 안정성 - 안정성은 변경을 만들기 위해 필요한 비용과 관련이 있다. 변경을 위한 비용이 크다면 안전하다고 말할 수 있다.. 2022. 7. 28.
[Clean Architecture 정리] 14장. 컴포넌트 결합 (1) 컴포넌트 결합 의존성 비순환 원칙 (ADP, Acyclic Dependency Principle) "컴포넌트 의존성 그래프에 순환(cycle)이 발생하면 안 된다." 개발팀에서 프로젝트를 진행하다보면, 오늘 정상적으로 실행되던 내 코드가 다음날 갑자기 오류가 발생하는 경우가 있다. 여러가지 이유가 있지만, 그 중 하나는 내 코드가 의존하는 어떤 것에 변경이 발생했기 때문이다. 책에서는 이를 '숙취 증후군(the morning after syndrome)' 이라 표현했는데, 아마도 변경에 대한 후유증으로 해석하면 될 것 같다. 이러한 문제의 해결책으로 두 가지를 제시한다. 첫번째는 '주 단위 빌드(Weekly Build)'로 독립된 환경해서 개발을 진행하다가 일주일에 한 번 통합하는 과정을 거친다는 것이다.. 2022. 7. 27.
[Clean Architecture 정리] 13장. 컴포넌트 응집도 컴포넌트 응집도 컴포넌트 응집도의 세 가지 원칙 - 재사용/릴리스 등가 원칙 (REP, Reuse/Release Equivalence Principle) - 공통 폐쇄 원칙 (CCP, Common Closure Principle) - 공통 재사용 원칙 (CRP, Common Reuse Principle) 재사용/릴리스 등가 원칙 (REP, Reuse/Release Equivalence Principle) - "재사용 단위는 릴리스 단위와 같다." - 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여되지 않으면 재사용할 수 없고, 컴포넌트들이 서로 호환되는지 보증할 수 없다. - 또한, 릴리스 번호를 통해 새로운 버전이 언제 출시되고 무엇이 변했는지 개발자가 알 수 있어야 한다. - .. 2022. 7. 25.

티스토리툴바