본문 바로가기

클린 아키텍처

5장 아키텍처 -업무규칙 업무규칙 : 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 핵심 업무 규칙 : 사업 자체에 핵심적인 업무규칙 ex) N%의 이자를 부과하다 더보기
5장 아키텍처 - 정책과 수준 정책 소프트웨어 시스템이란? 소프트웨어 시스템은 정책을 기술한것이다. 컴퓨터 프로그램은 각각의 정책을 상세하게 기술한 설명서이다. 시스템에서 하나의 정책은 이 정책을 서술하는 여러개의 작은 정책으로 쪼갤 수 있다. 아키텍처와 정책? 아키텍처는 이러한 여러정책들을 분리하고 재배치하는 일이다. 동일한 시점에 변경되는 정책은 동일한 수준에 위치하며,동일한 컴포넌트에 포함되어야하고 서로다른 이유,시점에 변경되는 정책은 다른 수준에 위치해야하며 다른 컴포넌트에 위치시켜 분리해야한다. 수준 수준이란? 수준은 정의하자면 입출력과의 거리이다. 입출력으로부터 멀어질 수록 수준은 높아진다. 위 그림에서 번역 컴포넌트는 가장 고수준의 컴포넌트에 속한다. 입력과 출력을 다루는 정책인 입력,출력은 가장낮은 수준의 컴포넌트이다... 더보기
5장 아키텍처 - 경계 : 선 긋기 경계란? 효율을 떨어트리는 결합(coupling)(특히 너무 일찍 내려지는 결정에 따른 결합)을 없애기 위해 요소를 서로 분리한다. 이때 이 두요소 사이에 하나의 선을 긋는데 이를 경계라고 한다. 즉 경계란 효율을 떨어트리는 결합(이른 결합)의 결정을 최대한 연기시켜 핵심비즈니스 로직을 오염시키지 못하게 만들게 해준다. 이른결정이란? 업무의 요구사항 즉 유스케이스와 관련없는 프레임워크,데이터베이스,웹 서버,유틸리티 라이브러리,의존성 주입에 대한 결정등이 여기에 포함된다. 좋은 사례(FitNesse) FitNesse는 로버트 C마틴과 아들 마키가 만든 소프트웨어다. 이 프로젝트는 개발 초기에 데이터베이스 사용에대한 결정을 최대한 나중으로 연기하였다. 이러한 결정으로 인해 FitNesse 프로젝트는 위키텍스.. 더보기
5장 아키텍처 - 독립성 유스케이스 유스케이스의 정의 시스템의 하나 이상의 액터 또는 이해관계자에게 관측 가능한 결과를 산출하는 시스템에 의해 수행되는 일련의 활동의 명세 출처 - 스마트그리드 표준화 시스템 아키텍처에서의 유스케이스 아키텍처는 시스템의 행위에 그다지 큰 영향을 주지 않습니다. 다만 좋은 아키텍처가 행위를 지원하기 위해서 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아 볼 수 있게 만들어야 한다. 좋은 아키텍처를 갖춘다면, 해당 시스템의 유스케이스는 시스템 구조 자체에서 한눈에 드러날 수 있습니다. 이들 행위는 일급 요소이며 시스템의 최상위 수준에서 알아 볼 수 있으므로, 일일히 찾아 헤매지 않아도 된다. 운영 시스템 운영차원에서 아키텍처는 더 실직적이며 덜 피상적인 역.. 더보기
5장 아키텍처 - 아키텍처란? 프로그래밍 아키텍처란? 시스템을 구축했던 사람들이 만들어낸 시스템의 형태다. 그 모양은 시스템을 컴포넌트로 분할하는 방법, 분할된 컴포넌트를 배치하는 방법, 컴포넌트가 서로 의사소통하는 방식에 따라 정해진다. 그리고 그 형태는 아키텍처 안에 담긴 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수 되도록 만들어진다. 시스템 아키텍처는 동작여부와 관련이 있는가? 아예 없다고는 할 수 없으나 거의 관련이 없다. 형편없는 아키텍처를 가지는 프로그램도 작동은 잘한다. 하지만 이러한 프로그램들은 운영,배포,유지보수에서 문제된다. 아키텍처의 주목적 시스템의 생명주기를 지원하는 것 이다. 좋은 아키텍처는 시스템을 쉽게 이해하고,쉽게 개발하며,쉽게 유지보수하고,쉽게 배포하게 해준다. 궁국적인 목표는 시스템의 수명과.. 더보기
4부 컴포넌트 원칙 - 컴포넌트 결합도 컴포넌트의 결합도 컴포넌트사이의 관계를 설명한다 ADP : 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환이 있어서는 안 된다. 소스코드를 작동하도록 작성하였는데 내 코드가 의존하는 소스가 누군가에 의해 수정되어 정상 작동하지 않는 것을 숙취 증후군이라고 한다. 이러한 숙취 증후근을 피하기 위한 해결책은 두가지가 있다. 주단위 빌드와 ADP이다. 주단위 빌드 각각의 개발자는 4일간 서로 신경쓰지 않고 개발한다. 그후 5일 째되는날(아마 금요일)에 통합 후 빌드한다. 장점 : 4일간 독립된 상태에서 개발 할 수 있다. 문제점 : 프로그램이 커질 수록 통합하는 시간이 늘어난다. 시간이 갈 수록 빌드 일정을 계속 늘려야한다. 통합과 테스트가 프로그램이 커질 수록 어려워 진다. 이에 팀이 주는 빠른 피드백의 .. 더보기
4부 컴포넌트 원칙 - 컴포넌트 응집도 컴포넌트 응집도 어떤 클래스를 어느 컴포넌트에 넣어야하는가? 이장에서는 이고민을 해결할 수 있는 3가지 원칙을 소개한다. 3가지 원칙 REP: 재사용/릴리스 등가 원칙 (Reuse/Release Equivalence Principle) 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 한다. 동일한 릴리스로 추적 관리, 동일한 릴리스 문서에 포함되어야 한다. CCP: 공통 폐쇄 원칙 (Common Closure Pr.. 더보기
4부 컴포넌트 원칙 - 컴포넌트 컴포넌트란? 컴포넌트는 시스템의 구성요소로 배포할 수 있는 가장 작은 단위 ex) 자바의 경우 jar파일이 하나의 컴포넌트가 될 수 있다. 예를 들어 마인크래프트의 모드 같은경우 jar파일을 이용하여 플러그인(모드 변경) 할 수 있다. 이때 이 jar하나는 마인크래프트라는 시스템의 구성요소로 적용 할 수 있으며 하나의 기능을 온전히 수행하는 작은 단위가 된다. 이 책에서의 컴포넌트 런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일 Why? 1) 컴포넌트의 역사 소프트웨어 초창기에는 메모리에서 프로그램 위치와 레이아웃을 프로그래머가 직정 제어했다. 또한 라이브러리 함수를 하나의 애플리케이션 코드에 포함시켜 컴파일 했다. 문제 컴파일 후 프로그램의 위치가 한번 결정되면 재배치 불가능 함수 라이브러리가.. 더보기

티스토리툴바