Clean Architecture

개념적으로 아키텍처는 고수준의 구조, 설계는 저수준의 세부사항이라고 정의되어 있지만, 실제로는 뚜렷하게 이 둘을 구분지을 수 없다. 이 둘의 사이에는 고수준에서 저수준으로 향하는 연속성만 존재한다.필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는 것새

모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치인 행동(behavior)와 구조(structure)를 제공한다.기능 명세서나 요구사항 문서를 구체화할 수 있도록 도우며, 기계가 이 요구사항을 만족하도록 프로그래머는 코드를 작성하고, 에러를 처리한다.하지

📕 구조적 프로그래밍 무분별한 점프문은 if/then/else나 do/while/until 구조로 대체한다. ** 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대해 규칙을 부과한다. ** 📗 객체 지향 프로그래밍 함수 → 클래스의 생성자 지역 변수 → 인스턴스

📕 증명 데이크스트라가 초기에 인식한 문제는 다음과 같다. 프로그래밍은 어렵다. 프로그래머는 프로그래밍을 잘하지 못한다. 데이크스트라는 증명(proof)이라는 수학적인 원리를 적용하여 이 문제를 해결하고자 했다. 순차 구문 분기 반복 데이크스트는 프로그래머가

📕 캡슐화 데이터와 함수를 쉽고 효과적으로 캡슐화하는 방법을 객체지향 언어가 제공한다. 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분 짓는 선을 그을 수 있다. 구분선 바깥에서 데이터는 은닉되고, 일부 함수만이 외부에 노출된다. (private 멤버, publ

📕 정수를 제곱하기 리스프에서 파생한 클로저(Clojure)는 함수형 언어이다. 리스프에서는 함수를 괄호 안에 넣는 방식으로 호출한다. 자바 프로그램은 가변 변수(Mutable variable)를 사용하는데, 가변 변수는 프로그램 실행 중에 상태가 변할 수 있다.

단일 책임 원칙은 하나의 일만 해야한다는 원칙이 아니다.하나의 모듈은 하나의 액터에 대해서만 책임져야 한다.이 세 가지 메서드가 서로 다른 액터에 영향을 주기 때문에 SRP를 위반한다.따라서, 서로 다른 액터가 의존하는 코드를 서로 분리해야 한다.하나의 소스 파일에 다

소프트웨어 개체(artifact)는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다. 즉, 소프트웨어 개체의 행위는 확장할 수 있어야 하지만, 이때 산출물을 변경해서는 안된다. 📕 사고 실험 소프트웨어 아키텍처가 훌륭하다면, 변경되는 코드의 양이 가능한

리스코프(Barbara Liskov)는 하위 타입(subtype)을 아래와 같이 정의 했다. S 타입의 객체 o1에 대응하는 T타입 객체 o2가 있다. → o1: S, o2: T T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환해도 P의 행위

위의 그림에서 User1: op1, User2: op2, User3: op3 만 사용한다고 하면, User1은 op2 와 op3 을 사용하지 않아도 해당 메서드에 의존하게 된다. 이러한 문제는 아래 그림처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결한다. 📕 ISP와 언어 언어 타입(정적, 동적 등)에 따라 소스 코드 의존성 여부가 다르다. 따...

유연성이 극대화된 시스템 : 소스 코드 의존성이 추상(abstraction)에 의존하며 구체(concretion)에는 의존하지 않는 시스템 우리가 의존하지 않도록 피하고자 하는 것은 바로 변동성이 큰(volatile) 구체적인 요소다. : 구체적인 요소 :

📍 컴포넌트 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위 컴포넌트가 마지막으로 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포가 가능해야 하며 독립적으로 개발 가능한 능력을 갖춰야 한다. 📕 컴포넌트의 간략한 역사 소프트웨어 개발

📕 REP: 재사용/릴리스 등가 원칙 > 재사용 단위는 릴리스 단위와 같다. 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 한다. 하나의 컴포넌트로 묶인 클래스와 모듈은 함께 릴리스 가능해야 한다. 📗 CCP: 공통 폐쇄 원칙 > 동일한 이유로 동일

📕 ADP: 의존성 비순환 원칙 > 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안 된다. 대규모 프로젝트에서 서로 의존하는 부분을 다른 사람이 건들여서 숙취 증후군이 발생한다. 이 문제의 해결책으로 다음 두 가지 방법이 있다. 주 단위 빌드(week

소프트웨어 아키텍트는 최고의 프로그래머이며, 코드와 동떨어져서는 안된다. 동시에,나머지 팀원들이 생산성을 극대화 할 수 있는 설계를 하도록 이끈다. 아키텍처의 주된 목적은 시스템의 생명주기를 지원하는 것이다. 좋은 아키텍처는 시스템을 쉽게 이해하고, 쉽게 개발하며,

좋은 아키텍처는 다음을 지원해야 한다. 시스템의 유스케이스 시스템의 운영 시스템의 개발 시스템의 배포 📕 유스케이스 시스템의 아키텍처는 시스템의 의도를 지원해야 한다는 뜻이다. 좋은 아키텍처가 행위를 지원하기 위해 할 수 있는 일 중에서 가장 중요한 사항은 행위를 명확히 하고 외부로 드러내며, 이를 통해 시스템이 지닌 의도를 아키텍처 수준에서 알아...

핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다. 이러한 유형의 객체를 엔티티(Entity)라고 부른다. 📕 엔티티 컴퓨터 시스템 내부의 객체 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화

📕 아키텍처의 테마 이바 야콥슨(ivar Jacobson)이 소프트웨어 아키텍처에 대해 쓴 독창적인 저서인 《Object Oriented Software Engineering》을 읽어보자. 이 책의 부제가 유스케이스 주도 접근법(Use Case Driven Approach)이라는 점을 주목하자. 야콥슨은 소프트웨어 아키텍처는 시스템의 유스케이스를 지원하...

다양한 아키텍처의 공통적인 목표는 관심사의 분리 이다. 계층으로 분리하여 관심사를 분리한다. 각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를 반드시 포함한다. 아키텍처들은 모두 시스템이 다음과 같은 특징을

📕 험블 객체 패턴 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게 하는 목적으로 고안 행위를 두개의 모듈이나 클래스로 나눈다. 이중 하나가 험블이다. 가장 기본적인 본질은 남기고, 테스트 하기 어려운 행위를 모두 험블 객체로 옮긴다. 나머지 모듈에는 험블 객체에 속하지 않은, 테스트하기 쉬운 행위를 모두 옮긴다. 험블 객체 패턴을 ...

📕 궁극적인 세부사항 메인 컴포넌트는 궁극적인 세부사항으로 가장 낮은 수준의 정책이다. 시스템의 초기 진입점 어떤 것도 메인에 의존 X 시스템에서 더 높은 수준을 담당하는 부분으로 제어권을 넘긴다. ex) 움퍼스 게임에서 main 함수에서 게임의 메인 루프, 입력 명령어 해석을 처리하지만 명령어의 실제 처리는 다른 고수준 컴포넌트로 위임시킴. 메인은 ...

📕 서비스 아키텍처 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다. 아키텍처 관점에서 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재한다. 이 장에서는 서비스 아키텍처의 장점에 대해 알아본다. 📗 서비스의 이점? 📍 결합 분리

📕 시스템 컴포넌트인 테스트 작은 테스트 이든, 대규모 테스트이든 아키텍처적으로 모두 동등하다. 테스트는 의존성 규칙을 따른다. 의존성은 항상 테스트 대상이 되는 코드를 향한다. 실제로 테스트는 아키텍처에서 가장 바깥쪽 원에 해당되며 시스템 내부의 어떤것도