클린아키텍처

둘 사이에는 아무런 차이가 없다.아키텍처 : 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용설계 : 저수준의 구조 또는 결정사항 등을 의미할 때가 많음. → 하지만 아키텍트가 실제로 하는 일을 살펴보면 이러한 구분은 무의미하다.

모든 소프트웨어 시스템은 이해관계자에게 행위, 구조라는 두 가지 가치를 제공해야 한다.소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 진다.불행히도 개발자는 한 가지 가치에만 집중하고 나머지 가치는 배제하곤 하는데 결국 소프트웨어 시스템이 쓸모

프로그래밍을 하는 방법으로, 대체로 언어에는 독립적이다.패러다임은 어떤 프로그래밍 구조를 사용할지, 그리고 언제 이 구조를 사용해야 하는지를 결정한다.현재까지 이러한 패러다임에는 세 가지 종류가 있다.최초로 적용된 패러다임(최초로 만들어진 패러다임은 아님).구조적 프로

소프트웨어를 과학으로 발전시키는데 큰 공헌을 함.데이크스트라가 해결하고자 하는 문제가 있었음.프로그래밍에 체계가 없기 때문에 프로그래밍을 하더라도 믿을 수 있는 결과를 내놓기 어려움.수학적 증명을 통해 이 문제를 해결하고자 하였음.수학적 증명은 실패소프트웨어가 과학적

좋은 아키텍처 좋은 아키텍처를 만드는 일은 객체 지향(Object-Oriented) 설계 원칙을 이해하고 응용하는 데서 출발한다. 객체지향이란? (1) 데이터와 함수의 조합 1966년 객체지향이 발명되기 이전부터 프로그래머는 데이터 구조를 함수에 전달해 왔다.

함수형 프로그래밍 개념은 프로그래밍 그 자체보다 앞서 등장.함수형 프로그래밍 패러다임의 핵심이 되는 기반은 람다(lambda) 계산법이다. 람다란? 자바 프로그램은 가변 변수(mutable variable)를 사용하는데, 가변 변수는 프로그램 실행 중에 상태가 변할

좋은 벽돌로 좋은 아키텍처를 정의하는 원칙.SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다.'클래스' 단어를 사용했다고 해서 SOLID 원칙이 객체 지향 소프트웨어에만 적용된다는 뜻은 아니다.여기에서

'소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.'소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 개체를 변경해서는 안된다.OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지

여기에서 필요한 것은 다음과 같은 치환(substitution) 원칙이다. S 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위

이미지 출처 : https://wedonttalknemore.tistory.com/17?category=967824다수의 사용자가 OPS 클래스의 오퍼레이션을 사용하고, 각 User별 매칭되는 오퍼레이션은 아래와 같다.User1 - op1만 사용 / User2

의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않는 시스템이다.자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인

컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위이다.잘 설계된 컴포넌트는 반드시 독립적으로 배포 가능한 즉, 독립적으로 개발 가능한 능력을 갖춰야 한다.런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일이 이 책에서 말하는 소프트웨어 컴포넌트에 해

컴포넌트 응집도에서 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움되는 원칙들을 살펴본다.컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적을 기준으로 구성되어야 한다.하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 하며, 동일한 릴

컴포넌트 사이의 의존성을 어떤 기준으로 만들 것인가를 살펴본다.ADP는 어떻게 하면 효율적인 통합을 할 수 있는가에 대한 해결책이다.릴리스 버전 단위의 컴포넌트 별로 분리하여 개발한다. → 다른 팀(컴포넌트)로부터의 영향이 작아진다. 컴포넌트 사이의 의존성 구조를

소프트웨어 시스템의 아키텍처란?사람들이 만들어낸 시스템의 형태다.이를 통해 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 만들어진다.개발팀들이 시스템을 쉽게 개발할 수 있도록 만드는데 도움을 주어야한다.소프트웨어 아키텍처는 시스템을 단 한번에 쉽게 배포할 수 있도록

비즈니스 업무규칙 중 애플리케이션을 통해 처리해야 업무사항을 뜻한다.시스템의 최고 정책은 비즈니스의 수익을 내거나 비용을 줄일 수 있는 업무규칙이다. 이러한 내용은 컴퓨터로 구현을 하는 것과 상관없이 수동으로도 진행해도 전혀 문제가 없는 것들이어야 한다.은행의 이자율

소프트웨어 아키텍처는 선을 긋는 기술이며, 이러한 선을 경계(boundary)라고 하자.프로젝트 초기에 만들어진 경계는 가능한 한 오랫동안 결정을 연기시키기 위해, 그래서 이들 결정이 핵심적인 업무 로직을 오염시키지 못하게 만들려는 목적으로 쓰인다.프레임워크, 데이터베

시스템 아키텍처는 소프트웨어 컴포넌트와 그 컴포넌트를 분리하는 경계에 의해 정의된다.경계는 다양한 형태로 나타난다.경계 형태 얘기를 하는데,, 결국 뭘 말하고자 하는지 잘 이해가 안됨.런타임에 경계를 횡단한다는 의미는 한쪽 경게에서 다른쪽으로 데이터를 넘기는 것을 말한

소프트웨어 시스템이란 정책을 기술한 것이며, 컴퓨터 프로그램은 각 입력을 출력으로 변환하는 정책을 상세하게 기술한 설명서이다.음식 주문 시스템은 주문과 관련된 정책을 말하는 것이며, 예를 들어 배달의 민족은 이런 음식 주문 시스템을 상세하고 구체적으로 기술한 설명서가

업무규칙이란 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다.컴퓨터상으로 구현했는지와 상관없이, 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다. 사람이 수동으로 직접 수행하더라도 마찬가지다.은행 - 대출시 N% 이자를 부과하는 것.이

좋은 아키텍처를 보면 어떤 시스템인지 파악할 수 있다.예를 들어 Xcode 디렉터리 구조, 패키지에 담긴 소스 파일을 보고 '헬스 케어 시스템'이구나 소리칠 수 있어야 한다.아키텍처는 유스케이스를 중점에 두어야 한다. 도서관 설계도의 유스케이스인 독서공간, 회의실,

수많은 시스템 아키텍처 아이디어가 있지만 그들의 공통점은 '관심사의 분리'다.모두 소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성할 수 있었다.각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를

험블객체는 아키텍처 경계 정의 및 테스트 용이성을 가지게 해준다는 점에서 중요한듯..험블 객체 패턴은 디자인 패턴으로 테스트하기 쉬운 행위와 테스트하기 어려운 행위를 분류한다.험블 객체 패턴은 행위를 두개의 모듈 혹은 클래스로 나눈다.테스트하기 어려운 모듈을 험블 객체

아키텍처 경계를 완벽하게 만들기 위해선 많은 비용이 든다.쌍방향의 다형적 Boundary 인터페이스, Input과 Output을 위한 데이터 구조 생성, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성 관리르 해야 하기 때문.

시스템 컴포넌트 크게 3가지(UI / 업무규칙 / 데이터베이스)로 구성된다고 생각할 수 있으나, 실제로 대규모 시스템에서는 그 이상이 될수도 있다. 다양한 언어로 지원되는 게임이며 게임 규칙은 어떤 언어 UI로 사용 되더라도 의존성을 잘 관리하면 그림과 같이 게임임 규

메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다.메인은 클린 아키텍처에서 가장 바깥 원에 위치하는 ,지저분한 저수준 모듈이다.메인은 고수준의 시스템을 위한 모든 것을 로드한 후, 제어권을 고수준의 시스템에게 넘긴다.움퍼스 사냥 게임의 메인은 입력 스트

서비스 지향 아키텍처 / 마이크로서비스 아키텍처가 유행이다.다음과 같은 이유로.상호 결합이 철저하게 분리된다.개발과 배포 독립성을 지원한다.그러나 이 두가지 이유는 일부만 맞는 말이다.서비스의 역할이 단순히 애플리케이션의 행위를 분리하는 것이라면 값비싼 함수를 호출하는

여러 테스트 종류가 있지만 중요한 것은 아키텍처 관점에서 모든 테스트가 동일하다는 점이다.테스트는 아키텍처에서 가작 바깥쪽 원으로 생각할 수 있다.시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다.테스

관계형 데이터베이스는 데이터를 저장하고 접근하는 데 탁월한 기술이다.그러나 관계형 데이터베이스도 결국 아키텍처 관점에서 보자면 세부사항이다.따라서 데이터를 테이블에 행 단위로 배치한다는 자체는 아키텍처적으로 볼 때 전혀 중요하지 않다.애플리케이션의 유스케이스는 이러한

모든 연산 능력을 중앙 서버에 두는 방식과 모든 연산 능력을 단말에 두는 방식 사이에서 끊임없이 움직여 왔다.웹 또한 이러한 진동을 겪고 있다. 연산능력의 위치는 아래와 같이 반복된다. 서버 팜(server farm) → 브라우저에 애플릿 추가 → 동적처리 서버로

프레임워크 제작자는 나를 위해서가 아니라 자신이나 자신의 동료와 친구들의 문제를 해결하기 위해 프레임워크를 제작한다.나는 프레임워크를 위해 헌신해야 하지만, 프레임워크 제작자는 나를 위해 헌신하지 않는다.대개의 경우 프레임워크 제작자들은 나의 애플리케이션이 가능하면 프

사례를 통해 지금까지 살펴 보았던 아키텍처에 대한 규칙과 견해를 종합적으로 살펴본다.뛰어난 아키텍트가 일을 처리하는 과정과 결정을 내리는 모습을 볼 수 있다.제품은 웹 사이트에서 비디오를 판매하는 소프트웨어이다.판매하길 원하는 비디오가 있으며, 개인과 기업에게 웹을 통

이 장은 시몬 브라운이 기고한 것으로, 클린 아키텍처를 실전에 도입시(코드화) 맞딱뜨릴 문제점과 해결책에 대해 설명한다.따라서 클린 아키텍처는 잠시 한쪽으로 제쳐 놓고, 설계나 코드 조직화와 관련된 몇 가지 접근법을 살펴보자.전형적인 계층형 아키텍처는 웹, 업무규칙,