cleanarchitecture (12) 썸네일형 리스트형 [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] 아키텍처란? 아키텍처란 단어는 중대한 결정과 심도 있는 기술적 기량을 떠올리게 한다. 소프트웨어 아키텍처는 기술적 성취의 정점에 서 있다. 이 소프트웨어 아키텍처를 결정하는 아키텍트에 대해 먼저 알아보자. 소프트웨어 아키텍트란? 무엇보다도 그들은 프로그래머이다. 앞으로도 계속 프로그래머이다. 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야한다는 말은 거짓 절대로 코드와 멀어져서는 안된다. 프로그래밍 작업을 계속할 뿐만 아니라 동시에 나머지 팀원들의 생산성을 극대화 할 수 있는 설계 방향을 이끌어낸다. 소프트웨어 아키텍처란? 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 시스템의 형태는 시스템을 컴포넌트로 분리하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트의 의사소통 방식에 따라 달라진다. 그 방.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(3) : SAP SAP(안정된 추상화 원칙)이란? 컴포넌트는 안정된 정도만큼만 추상화되어야 한다. 고수준 정책은 어디에 위치시켜야하는가? 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경해서는 절대로 안 되는 소프트웨어 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다. 하지만 안정된 컴포넌트에 위치 시킨다면 변경이 어려운 단점이 있음. (유연성이 떨어짐) 추상 클래스를 통해 컴포넌트가 최고로 안정된 상태(I=0)이면서도 동시에 유연하게 만들 수 있다. 안정된 추상화 원칙 (Stable Abstractions Principle) 안정성과 추상화 정도 사이의 관계를 정의. 안정된 컴포넌트는 추상 컴포넌트여야 함(인터페이스와 추상 클래스로 구성). 이를 통해 안정성이 컴포넌트를.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(2) : SDP SDP(안정된 의존성 원칙)란? 안정성의 방향으로(더 안정된 쪽에) 의존하라 즉, 변경하기 어려운 모듈이 변경하기 쉽게 만들어진 모듈에 의존하지 않도록 만들어야한다. 그렇다면 안전성이란? 사전적으로는 ‘쉽게 움직이지 않는’으로 정의. 안정성은 변경을 위해 필요한 작업량과 관련된다. 안정성이 높으면 상당한 작업량이 필요함. (탁자를 뒤집는 것과 옆으로 세워진 동전을 넘어뜨리는 것을 생각해보자) 소프트웨어 관점에서의 안정성 컴포넌트 변경이 어려운 요인에는 크기, 복잡도, 간결함 등이 있음. 컴포넌트 변경이 어려운 가장 확실한 방법은 “수많은 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.” 안정적인 컴포넌트 - X는 안정된 컴포넌트. - 세 컴포넌트가 x에 의존함에 따라 X컴포넌트는 변경하지 말아야할 이.. [Clean Architecture] 컴포넌트 응집도 이번에는 컴포넌트 응집도와 관련된 3가지 원칙을 알아보자. 1. REP(Reuse/Release Equivalence Principle) : 재사용 / 릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다. (당연한 사실!!) 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 한다. 동일한 릴리스로 추적 관리, 동일한 릴리스 문서에 포함되어야 한다. CCP와 CRP는 REP를 엄격하게 제약을 가하는 측면에서 정의한다. .. [Clean Architecture]SOLID 원칙 : 5.DIP 의존성 역전 원칙 DIP 란? 의존성 역전 원칙은 유연성을 극대화시키는데 그 목적이 있다. 이는 소스 코드 의존성이 추상(abstraction)에 의존하며, 구체(concretion)에는 의존하지 않는 시스템을 이야기한다. 즉, 정적 타입의 언어에서는 use, import, include를 통해 인터페이스 혹은 추상 클래스와 같은 추상적인 선언만 참조해야한다는 뜻이다. 하지만 정적타입 언어인 JAVA를 예로들면, String이나 Integer와 같은 구체클래스도 사용하면 안된다는 걸까? 그렇지 않다. String이나 Integer와 같은 클래스는 매우 안정적인 클래스 이기 때문에 변경되는 일이 적다. 따라서 DIP를 논할 때, 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 무시하는 편이다. 즉, 우리가 주의해야할.. 이전 1 2 다음
