본문 바로가기
반응형

클린아키텍처19

[클린아키텍처] 26장 메인 컴포넌트, 27장 크고 작은 모든 서비스들 메인 Main 컴포넌트 : 시스템에서 나머지 컴포넌트를 생성하고, 조정하며 관리한다. 가장 낮은 수준의 정책 시스템의 초기 진입점 의존성 주입 프레임워크를 이용해 의존성을 주입한다. 입력 스트림 생성 부분, 게임의 메인 루프 처리, 간단한 입력 명령어 해석 등 처리, 명령어를 실제로 처리하는일은 다른 고수준 컴포넌트로 위임한다. 애플리케이션의 플러그인 (초기 조건과 설정을 구성하고, 외부 자원을 모두 수집한 후 제어권을 애플리케이션의 고수준 정책으로 넘기는 플러그인) 메인 컴포넌트를 둘 이상으로 만들 수 있다. ex) 개발용 메인 플러그인, 테스트용 메인 플러그인, 상용 메인 플러그인, 국가별 메인 플러그인, 영역별 메인 플러그인, 고객별 메인 플러그인 서비스 지향 아키텍처, 마이크로서비스 아키텍처가 인.. 2022. 3. 16.
[클린아키텍처] 23장 프레젠터와 험블 객체, 24장 부분적 경계, 25장 계층과 경계 험블 객체 패턴 Humble Object : 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안된 디자인 패턴 행위들을 두개의 모듈 또는 클래스로 나눈다. 이 모듈 중 하나가 험블이다. 가장 기본적인 본질을 남기고 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. ex) GUI의 경우 화면에 각 요소가 필요한 위치에 적절히 표시되었는지 검사하는 테스트는 작성하기가 어렵다. 하지만 GUI에서 수행하는 행위의 대다수는 쉽게 테스트 가능하다. -> 험블 객체 패턴을 사용하여 프레젠터와 뷰라는 서로 다른 클래스로 만들 수 있다. humble 1. 겸손한 2. (예의상 자기를 낮추는 표현에서) 변변치 않은, 1. 겸손한 2. 변변찮은, 작은, 겸손한 행위를 테.. 2022. 3. 13.
[클린아키텍처] 21장 소리치는 아키텍처, 22장 클린 아키텍처 좋은 아키텍처는 유스케이스를 중심으로 만든다. 프레임워크, 데이터베이스, 웹서버 등의 개발환경을 중심으로 만들면 안된다. -> 프레임워크는 도구일뿐이다. 웹 또한 전달 메커니즘(입출력 장치)이며, 시스템 아키텍처에는 영향을 주지 않는다. -> 아키텍처 수정 없이도 시스템을 웹, 앱, 콘솔앱 등 전달할 수 있어야 한다. 프레임워크, 웹서버, 데이터베이스 없이도 유스케이스 전부에 대해 단위 테스트가 가능해야한다. -> 유스케이스 객체가 엔티티 객체(데이터베이스나 프레임워크 아닌 간단한 객체)를 조작해야 한다. 지난 수십년 간 시스템 아키텍처와 관련된 여러 아이디어가 있다. 육각형 아키텍처 Hexagonal Archiecture DCI (Data Context and Interaction) BCE (Bound.. 2022. 3. 12.
[클린아키텍처] 19장 정책과 수준, 20장 업무 규칙 수준 Level : 입력과 출력까지의 거리 시스템의 입려과 출력 모두로부터 멀리 위치할수록 정책의 수준은 높아진다. 입력과 출력을 다루는 정책이라면 시스템에서 최하위 수준에 위치한다. 간단한 암호화 프로그램 입력장치에서 문자를 읽기 -> 테이블을 참조하여 번역 -> 번역된 문자를 출력장치로 기록 번역 컴포넌트는 최고수준의 컴포넌트 (입력과 출력에서 가장 멀리떨어져있기 때문) 소스코드 의존성과 데이터흐름은 같은 방향이 아니다. 업무 규칙 Critical Business Data 애플리케이션을 업무 규칙과 플러그인으로 구분하려면 업무 규칙을 잘 이해해야한다. 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다. 핵심 업무 데이터 : 핵심 업무 규칙에서 요구하는 데이터 엔티티 Entity : 컴.. 2022. 3. 11.
[클린아키텍처] 17장 경계: 선긋기, 18장 경계 해부학 경계 Boundary 소프트 웨어 아키텍처는 경계 Boundary 를 긋는 기술이다. 소프트웨어 요소를 서로 분리하고, 경계 한편에 있는 요소가 반대편에 있는 요소를 알지 못하도록 막는다. 프로젝트 초기 또는 매우 나중에 생길 수 있다. 결합 coupling 경계와 반대되는 기술 인적자원 효율을 떨어뜨리는 요인 유스케이스와 관련없는 프레임워크, DB, 웹서버, 라이브러리 등 너무 일찍 내려진 결정에 따른 결합 좋은 아키텍처는 이러한 결정이 부수적이며, 결정을 나중에 내려도 큰 영향이 없어야한다. 어떻게 선을 그을까? 언제 그을까? 1 GUI와 업무 규칙은 선이 있어야한다. O 2 데이터베이스와 GUI도 선이 있어야한다. O 3 데이터베이스와 업무규칙도 선이 있어야한다 O -> ??? 데이터베이스가 업무 .. 2022. 3. 10.
[클린아키텍처] 15장 아키텍처란?, 16장 독립성 소프트웨어 시스템 아키텍처 : 시스템을 구축했던 사람들이 만들어낸 시스템의 형태 목적: 시스템의 생명주기를 지원하는 것 궁극적인 목표: 시스템의 수명과 관련된 비용은 최소화, 프로그래머의 생산성은 최대화 소프트웨어 시스템이 쉽게 개발, 배포, 운영 유지보수되게 만드려면 가능한 많은 선택지를, 가능한 오래 남겨두는 전략을 따라야한다. 개발 배포 운영 유지보수 아키텍트의 목표는 시스템에서 정책을 가장 핵심적인 요소로 식별하고, 동시에 세부사항은 정책에 무관하게 만들 수 있는 형태의 시스템을 구축하는 것 개발 초기에는 데이터베이스 시스템을 선택할 필요가 없다 개발 초기에는 웹서버를 선택할 필요가 없다. 개발 초기에는 REST를 적용할 필요가 없다. 개발 초기에는 의존성 주입 프레임워크를 적용할 필요가 없다. .. 2022. 3. 6.
[클린아키텍처] 12장~14장 컴포넌트 원칙 SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 알려준다. 컴포넌트 : 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위 ex) 자바의 컴포넌트 = jar 파일, 루비의 컴포넌트 = gem 파일. 닷넷의 컴포넌트 = DLL 파일 잘 설계된 컴포넌트는 독립적으로 배포 가능해야한다 컴포넌트 응집도 - 어떤 클래스를 어떤 컴포넌트에 포함시켜야할까? 1. REP (Reuse/Release Equivalence Principle) : 재사용/릴리스 등가 원칙 : 재사용 단위는 릴리스 단위와 같다 릴리스 절차에는 적절한 공지와 함께 문서 작성도 포함되어야 한다. -> 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성돼야한다. -> 하나의 컴포넌트로 묶.. 2022. 3. 6.
[클린아키텍처] 7장~11장 설계원칙 - SOLID 원칙 객체지향의 5가지 설계 원칙이 있다. SRP OCP LSP ISP DIP SRP (Single-responsibility principle) 단일 책임 원칙 : 하나의 모듈은 하나의 액터에 대해서만 책임져야 한다. : 클래스는 단 하나의 기능만 갖고, 제공하는 서비스는 그 기능을 수행한다. 응집성 : 단일 액터를 책임지는 코드를 함께 묶어주는 힘 응집성을 위반하는 징후 1: 우발적 중복 응집성을 위반하는 징후 2: 병합 SRP 예제 참고 [SRP] 객체지향 설계 5 원칙 (1) 학습목표 : SRP[Single responsibility principle] 단일 책임 원칙 을 이해하고, 예제로 설명할 수 있다. SRP[Single responsibility principle] 단일 책임 원칙 - 한 클래스.. 2022. 2. 27.
[클린아키텍처] 3장~6장 프로그래밍 패러다임 - 구조적 프로그래밍, 객체 지향 프로그래밍, 함수형 프로그래밍 구조적 프로그래밍, 객체 지향 프로그래밍, 함수형 프로그래밍 이 세가지 패러다임은 무엇을 해서는 안되는지를 말해준다. 1. goto문 2. 함수 포인터 3. 할당문 구조적 프로그래밍 : 제어프흠의 직접적인 전환에 대해 규칙을 부과한다. goto문의 좋은 사용방식은 if/then/else 와 do/while 같은 분기와 반복이라는 단순한 제어구조이다. 객체 지향 프로그래밍 (OO) : 제어흐름의 간접적인 전환에 대해 규칙을 부과한다. 좋은 아키텍처를 만드는 일은 객체지향 설계 원칙을 이해하고 응용하는 데서 출발한다. 객체지향은 캡슐화, 상속, 다형성을 반드시 지원해야한다. 캡슐화 : 데이터와 함수가 응집력있게 구성된 집단을 서로 구분 짓는다. -> 구분선 바깥에서 데이터는 은닉되고, 일부 함수만이 외부에 .. 2022. 2. 27.
728x90
반응형