Design/Architecture (17) 썸네일형 리스트형 [Clean Architecture] 아키텍처 - 험블 객체 (Humble Object) 험블 객체 패턴 (Humble Object Pattern) 이란? 험블 객체 패턴은 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다. 테스트가 어려운 행위들을 단위테스트가 쉬운 행위, 테스트가 어려운 행위 두가지 모듈 또는 클래스로 나누는 것이다. 테스트가 어려운 모듈이 험블 객체 부분이다. 테스트의 용이성은 아키텍처에 중요한 요소인데, 험블 객체 패턴이 좋은 예이다. 험블 객체 패턴의 예시들 1) 프레젠터와 뷰 뷰 : 험블 객체이고 테스트하기 어렵다. - 뷰 객체에 포함된 코드는 가능한 한 간단하게 유지. - 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다. 프레젠터 : 테스트하기 쉬운 객체이다. - 프.. [Clean Architecture] 아키텍처 - 업무규칙 (Entity, Use case) 여태까지 수차례 언급해왔던 업무규칙에 대해서 알아보는 시간을 가져보자. 애플리케이션을 업무규칙과 플러그인으로 구분하려면 업무규칙이 무엇인지 정확히 이해할 필요가 있다. 업무규칙이란? 업무규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 업무규칙은 컴퓨터로 구현을 했던 사람이 수동으로 수행을 하던 동일하다. 이러한 규칙을 "핵심 업무 규칙(Critical Business Rules)"라고 부른다. 핵심 업무 규칙은 보통 데이터를 요구하는데 이러한 데이터를 "핵심 업무 데이터(Critical Business Data)"라고 부른다. ex) 대출에는 대출 잔액, 이자율, 지급 일정 데이터가 필요하다. 핵심 업무 규칙과 핵심 업무 데이터는 본질적으로 결합이 되어있기 때문에 객체로 만들 충.. [Clean Architecture] 아키텍처 - 경계 소프트웨어 아키텍처는 선을 긋는 기술이며, 저자는 이러한 선을 경계라고 부른다. 경계의 역할 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다. 경계는 프로젝트 수명 중 초기에 그어지는 경우도 있고, 어떤 경우는 매우 나중에 그어지는 것도 있다. 초기에 그어지는 선들은 가능한 한 오랫동안 결정을 연기하여, 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적이 있다. 경계와 아키텍트의 목표 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것. 인적 자원의 효율을 떨어뜨리는 요인은 결합이다. 특히 너무 일찍 내려진 결정에 따른 결합이다. 시스템의 업무 요구사항(유스케이스)와 관련없는 프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등. 좋은 .. [Clean Architecture] 아키텍처 - 독립성 아키텍처의 독립성을 알아보기전 좋은 아키텍처가 지원해야하는 것에 대해서 먼저 알아보도록하자. 좋은 아키텍처가 지원해야하는 것 좋은 아키텍처는 다음 네가지를 지원해야한다. 시스템의 유스케이스 시스템의 운영 시스템의 개발 시스템의 배포 1) 유스케이스 기본적으로 아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않음 하지만 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중 가장 중요한 일은 행위를 명확히 하고 외부로 드러내며, 이를통해 시스템이 지닌 의도롤 아키텍처 수준에서 알아볼 수 있게 만드는 것이다. 따라서 개발자가 일일이 일급요소(행위)를 찾아 헤매지 않아도 된다. "소리치는 아키텍처" 챕터를 꼭 참고해보자 2) 운영 시스템 운영의 차원에서 아키텍처는 더 실질적인 역할을 맡는다. 아키텍처는 각.. [Clean Architecture] 아키텍처란? 아키텍처란 단어는 중대한 결정과 심도 있는 기술적 기량을 떠올리게 한다. 소프트웨어 아키텍처는 기술적 성취의 정점에 서 있다. 이 소프트웨어 아키텍처를 결정하는 아키텍트에 대해 먼저 알아보자. 소프트웨어 아키텍트란? 무엇보다도 그들은 프로그래머이다. 앞으로도 계속 프로그래머이다. 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야한다는 말은 거짓 절대로 코드와 멀어져서는 안된다. 프로그래밍 작업을 계속할 뿐만 아니라 동시에 나머지 팀원들의 생산성을 극대화 할 수 있는 설계 방향을 이끌어낸다. 소프트웨어 아키텍처란? 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 시스템의 형태는 시스템을 컴포넌트로 분리하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트의 의사소통 방식에 따라 달라진다. 그 방.. [Architecture 공부] CQRS에 대해서 알아보자. CQRS란? Command and Query Responsibility Segregation(명령과 조회의 책임 분리)를 나타낸다. 말그대로 시스템에서 명령을 처리하는 책임과 조회를 처리하는 책임을 분리하는 것이 핵심. 명령 : 시스템의 상태를 변경하는 작업. 조회 : 시스템의 상태를 반환하는 작업. 즉 명령과 조회로 작업의 책임을 분리하는 것. CQRS가 필요한 이유. Application의 BIZ정책이나 제약(비즈니스 로직)은 대부분 데이터 변경 (C,U,D) 작업에서 처리되고, 데이터 조회(R)작업은 단순 데이터 조회가 대부분. 두 역할을 하나의 동일한 Domain Model로 처리하게 되면, 각 업무 영역에서의 새로운 요구사항으로 인한 Model 변경이 누적되면서 C,U,D를 위한 모델과 조회를 .. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(3) : SAP SAP(안정된 추상화 원칙)이란? 컴포넌트는 안정된 정도만큼만 추상화되어야 한다. 고수준 정책은 어디에 위치시켜야하는가? 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경해서는 절대로 안 되는 소프트웨어 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다. 하지만 안정된 컴포넌트에 위치 시킨다면 변경이 어려운 단점이 있음. (유연성이 떨어짐) 추상 클래스를 통해 컴포넌트가 최고로 안정된 상태(I=0)이면서도 동시에 유연하게 만들 수 있다. 안정된 추상화 원칙 (Stable Abstractions Principle) 안정성과 추상화 정도 사이의 관계를 정의. 안정된 컴포넌트는 추상 컴포넌트여야 함(인터페이스와 추상 클래스로 구성). 이를 통해 안정성이 컴포넌트를.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(2) : SDP SDP(안정된 의존성 원칙)란? 안정성의 방향으로(더 안정된 쪽에) 의존하라 즉, 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들어야한다. 그렇다면 안전성이란? 사전적으로는 ‘쉽게 움직이지 않는’으로 정의. 안정성은 변경을 위해 필요한 작업량과 관련된다. 안정성이 높으면 상당한 작업량이 필요함. (탁자를 뒤집는 것과 옆으로 세워진 동전을 넘어뜨리는 것을 생각해보자) 소프트웨어 관점에서의 안정성 컴포넌트 변경이 어려운 요인에는 크기, 복잡도, 간결함 등이 있음. 컴포넌트 변경이 어려운 가장 확실한 방법은 “수많은 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.” 안정적인 컴포넌트 - X는 안정된 컴포넌트. - 세 컴포넌트가 x에 의존함에 따라 X컴포넌트는 변경하지 말아야할 이.. 이전 1 2 3 다음
