본문 바로가기

분류 전체보기

 (48)
[Clean Architecture] 아키텍처 - 험블 객체 (Humble Object) 험블 객체 패턴 (Humble Object Pattern) 이란? 험블 객체 패턴은 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다. 테스트가 어려운 행위들을 단위테스트가 쉬운 행위, 테스트가 어려운 행위 두가지 모듈 또는 클래스로 나누는 것이다. 테스트가 어려운 모듈이 험블 객체 부분이다. 테스트의 용이성은 아키텍처에 중요한 요소인데, 험블 객체 패턴이 좋은 예이다. 험블 객체 패턴의 예시들 1) 프레젠터와 뷰 뷰 : 험블 객체이고 테스트하기 어렵다. - 뷰 객체에 포함된 코드는 가능한 한 간단하게 유지. - 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다. 프레젠터 : 테스트하기 쉬운 객체이다. - 프..
[Clean Architecture] 아키텍처 - 업무규칙 (Entity, Use case) 여태까지 수차례 언급해왔던 업무규칙에 대해서 알아보는 시간을 가져보자. 애플리케이션을 업무규칙과 플러그인으로 구분하려면 업무규칙이 무엇인지 정확히 이해할 필요가 있다. 업무규칙이란? 업무규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 업무규칙은 컴퓨터로 구현을 했던 사람이 수동으로 수행을 하던 동일하다. 이러한 규칙을 "핵심 업무 규칙(Critical Business Rules)"라고 부른다. 핵심 업무 규칙은 보통 데이터를 요구하는데 이러한 데이터를 "핵심 업무 데이터(Critical Business Data)"라고 부른다. ex) 대출에는 대출 잔액, 이자율, 지급 일정 데이터가 필요하다. 핵심 업무 규칙과 핵심 업무 데이터는 본질적으로 결합이 되어있기 때문에 객체로 만들 충..
[Clean Architecture] 아키텍처 - 경계 소프트웨어 아키텍처는 선을 긋는 기술이며, 저자는 이러한 선을 경계라고 부른다. 경계의 역할 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다. 경계는 프로젝트 수명 중 초기에 그어지는 경우도 있고, 어떤 경우는 매우 나중에 그어지는 것도 있다. 초기에 그어지는 선들은 가능한 한 오랫동안 결정을 연기하여, 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적이 있다. 경계와 아키텍트의 목표 필요한 시스템을 만들고 유지하는 데 드는 인적 자원을 최소화하는 것. 인적 자원의 효율을 떨어뜨리는 요인은 결합이다. 특히 너무 일찍 내려진 결정에 따른 결합이다. 시스템의 업무 요구사항(유스케이스)와 관련없는 프레임워크, 데이터베이스, 웹 서버, 유틸리티 라이브러리, 의존성 주입에 대한 결정 등. 좋은 ..
[소식] Log4j2 보안취약성 이슈 이번에 발견된 Log4j관련 취약성과 관련하여 잘 설명된 기사가 있어 해석 및 정리하여 올립니다. ****** 2021년 12월 9일 자바기반의 로깅 패키지로 유명한 Log4j의 취약점이 드러났습니다. 이 취약성으로 인해 공격자는 리모트 서버에 코드를 실행할 수 있습니다(Remote Code Execution, RCE). 상당히 많은 곳에서 자바를 사용하고 있고 또한 Log4j를 함께 이용하고 있기 때문에 더욱 치명적이라고 생각이 됩니다. 취약점 보완이 필요한 Log4j버전 - 2.0-beta-9 ~ 2.14.1 사이의 버전. 보완방법 Log4j v2.16.0으로 업그레이드하기. (v2.15.0 에서 v2.16.0 으로 업데이트 [관련링크] - 21.12.15) Log4j v2.10 혹은 그이상의 버전을..
[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) 안정성과 추상화 정도 사이의 관계를 정의. 안정된 컴포넌트는 추상 컴포넌트여야 함(인터페이스와 추상 클래스로 구성). 이를 통해 안정성이 컴포넌트를..

티스토리툴바