클린아키텍처 (10) 썸네일형 리스트형 [DDD 첫걸음] 2-4. 전술적 설계 - 아키텍처 패턴 이번장 에서는 시스템의 구성요소 간의 상호작용과 의존성을 조율하는 다양한 방법을 살펴본다.비즈니스 로직과 아키텍처 패턴비즈니스 로직은 소프트웨어에서 가장 중요한 요소.하지만 그 외에도 코드베이스에는 입력과 출력, 다양한 저장소에 상태를 저장하고 타 시스템 및 Service provider와의 연동 등의 요소들도 존재. 이렇듯 코드베이스에는 다양한 관심사가 있기 때문에 각 관심사에 맞게 엄격한 구성이 필요하며, 비즈니스 로직이 흩어지는 것을 방지해야함. (유지보수의 용이성)아키텍처 패턴은 코드베이스의 다양한 측면에 대한 구성 원칙을 도입하고 이들 사이의 명확한 경계를 제시.코드 베이스를 조직하는 적절한 방법 혹은 올바른 아키텍처 패턴을 선택하는 것은 단기적으로는 비즈니스 로직 구현을 지원.장기적으로는 유지.. [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] 아키텍처란? 아키텍처란 단어는 중대한 결정과 심도 있는 기술적 기량을 떠올리게 한다. 소프트웨어 아키텍처는 기술적 성취의 정점에 서 있다. 이 소프트웨어 아키텍처를 결정하는 아키텍트에 대해 먼저 알아보자. 소프트웨어 아키텍트란? 무엇보다도 그들은 프로그래머이다. 앞으로도 계속 프로그래머이다. 아키텍트라면 코드에서 탈피하여 고수준의 문제에 집중해야한다는 말은 거짓 절대로 코드와 멀어져서는 안된다. 프로그래밍 작업을 계속할 뿐만 아니라 동시에 나머지 팀원들의 생산성을 극대화 할 수 있는 설계 방향을 이끌어낸다. 소프트웨어 아키텍처란? 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 시스템의 형태는 시스템을 컴포넌트로 분리하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트의 의사소통 방식에 따라 달라진다. 그 방.. [Clean Architecture] 컴포넌트 사이의 관계와 원칙(3) : SAP SAP(안정된 추상화 원칙)이란? 컴포넌트는 안정된 정도만큼만 추상화되어야 한다. 고수준 정책은 어디에 위치시켜야하는가? 고수준 아키텍처나 정책 결정과 관련된 소프트웨어는 자주 변경해서는 절대로 안 되는 소프트웨어 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다. 하지만 안정된 컴포넌트에 위치 시킨다면 변경이 어려운 단점이 있음. (유연성이 떨어짐) 추상 클래스를 통해 컴포넌트가 최고로 안정된 상태(I=0)이면서도 동시에 유연하게 만들 수 있다. 안정된 추상화 원칙 (Stable Abstractions Principle) 안정성과 추상화 정도 사이의 관계를 정의. 안정된 컴포넌트는 추상 컴포넌트여야 함(인터페이스와 추상 클래스로 구성). 이를 통해 안정성이 컴포넌트를.. [Clean Architecture] 컴포넌트 응집도 이번에는 컴포넌트 응집도와 관련된 3가지 원칙을 알아보자. 1. REP(Reuse/Release Equivalence Principle) : 재사용 / 릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다. (당연한 사실!!) 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 한다. 동일한 릴리스로 추적 관리, 동일한 릴리스 문서에 포함되어야 한다. CCP와 CRP는 REP를 엄격하게 제약을 가하는 측면에서 정의한다. .. 이전 1 2 다음
