독서록/Clean Architecture

[Clean Architecture] 4부: 컴포넌트 원칙 - 14장 컴포넌트 결합

ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안 된다. 순환이 생기면 컴포넌트를 분리하기가 상당히 어려워진다. 단위 테스트를 하고 릴리스를 하는 일도 굉장히 어려워지며 에러도 쉽게 발생한다. 게다가 모듈의 개수가 많아짐에 따라 빌드 관련 이슈는 기하급수적으로 증가한다. 뿐만 아니라 의존성 그래프에 순환이 생기면 어떤 순서로 빌드해야 올바를지 파악하기가 상당히 힘들어진다. 사실 순환이 생기면 올바른 순서라는 것 자체가 없을 수 있다. 순환을 끊는 방법 의존성 역전 원칙(DIP)을 적용한다. 인터페이스를 통해 의존성을 역전시키는 방법이다. 모두가 의존하는 새로운 컴포넌트를 만든다. 그리고 의존하는 클래스들을 새로운 컴포넌트로 이동시킨다. 하향식(top-down) 설계 컴..

[Clean Architecture] 4부: 컴포넌트 원칙 - 13장 컴포넌트 응집도

REP: 재사용/릴리스 등가 원칙(Reuse/Release Equivalence Principle) 재사용 단위는 릴리스 단위와 같다. 소프트웨어 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것이다. 릴리스 번호가 없다면 재사용 컴포넌트들이 서로 호환되는지 보증할 방법이 전혀 없다. 또한 릴리스 번호를 통해 새로운 버전이 언제 출시되고 무엇이 변했는지를 소프트웨어 개발자들이 알아야 한다. 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다. 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다. 하나의 컴포넌..

[Clean Architecture] 3부 설계 원칙: SOLID

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다. SOLID 원칙의 목적은 변경에 유연한, 이해하기 쉬운, 많은 소프트웨어 시스템 컴포넌트의 기반이 되는 소프트웨어 아키텍처를 만들고자 함. 7장 SRP: 단일 책임 원칙 하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임져야 한다는 원칙. 1. 원칙을 위반하는 징후 1: 우발적 중복 하나의 컴포넌트에 대한 변경 사항이 다른 컴포넌트에도 영향을 미치는 문제. SRP는 서로 다른 액터(변경을 요하는 집단)가 의존하는 코드를 각각 분리시키라고 말한다. 2. 원칙을 위반하는 징후 2: 병합 둘 이상의 사람이 서로 다른 목적으로 동일한 소스 파일을 변경하는 경우 병합(충돌)이 발생..

[Clean Architecture] 2부 벽돌부터 시작하기: 프로그래밍 패러다임

3장 패러다임 개요 1. 구조적 프로그래밍 최초로 적용된 패러다임. 구조적 프로그래밍은 제어 흐름의 직접적인 전환에 대해 규칙을 부과한다. 2. 객체 지향 프로그래밍 함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었다. 객체 지향 프로그래밍은 제어 흐름의 간접적인 전환에 대해 규칙을 부과한다. 3. 함수형 프로그래밍 람다 계산법의 기초가 되는 개념은 불변성(immutability)으로 심볼(symbol)의 값이 변경되지 않는다는 개념이다. 이는 함수형 언어에는 할당문이 전혀 없다는 뜻이기도 하다. 함수형 프로그래밍은 할당문에 대해 규칙을 부과한다. 각 패러다임은 일종의 추가적인 규칙을 부과한다. 즉, 패러다임은 무엇을 해야 할지를 말하기보다는 무엇을 해서는 안 되는지..

[Clean Architecture] 1부 소개

옮긴이의 글 소프트웨어 시스템이란 무엇인지를 우리는 제대로 이해하고 있을까? 소프트웨어 시스템을 통해서 우리가 얻고자 하는 것은 무엇일까? 잘 설계한 소프트웨어 아키텍처는 소프트웨어 시스템을 만들 때 왜 중요할까? 중요하다면 어떻게 해야 소프트웨어 아키텍처를 잘 만들 수 있을까? 1장 설계와 아키텍처란? 우선 설계와 아키텍처 사이에는 차이가 없다. 둘은 동일하다. 소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지 보수하는 데 투입되는 인력을 최소화하는 데 있다. 고객의 요구를 만족시키는 데 드는 비용이 낮을 뿐만 아니라 시스템의 수명이 다할 때까지 낮게 유지할 수 있다면 좋은 설계, 새로운 기능을 출시할 때마다 비용이 증가한다면 나쁜 설계이다. 개발자는 훌륭하고 깔끔하게 잘 설계된 코드가 중요하다..