Clean Architecture

Architecture

1960년대나 1950년대와 마찬가지로 코드는 여전히 순차, 분기, 반복의 집합체일 뿐이다.
컴퓨터 프로그래밍을 하는 관행을 정말 유심히 관찰해 보면 지난 50년 동안 변한 게 거의 없다는 것을
알게 된다. 언어는 조금 발전했고 도구는 환상적으로 좋아졌다. 하지만 컴퓨터 프로그래밍을 이루는
기본적인 구성 요소는 조금도 바뀌지 않았다.

설계와 아키텍처의 차이

1. 둘 사이에는 차이가 없다.

 

 - 보통 '아키텍처'란 저수준의 세부하상과는 분리된 고수준의 무언가를 가리킬 때 사용된다.

 - 보통 '설계'란 저수준의 구조 또는 결정 사항 등을 의미할 때가 많다.

   => 하지만 아키텍트가 실제로 하는 일을 살펴보면 이런 구분은 무의미하다.

Ex) 새로운 집을 설계하는 아키텍트

 - 이 집의 아키텍처는 집의 형태, 외관, 입면도, 공간이나 방의 배치 등이 포함된다. 

   하지만 이집의 도면을 살펴보면 무수히 많은 저수준의 세부사항도 확인할 수 있다. 콘센트, 전등 스위치, 전등의 위치 등

    또한 도면에서 알 수 있다.

 => 모든 고수준의 결정 사항을 지챙하는 모든 세부사항을 자세하게 확인할 수 있다.

 

소프트 웨어의 두가지 가치 

1. 행위

 - 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해 프로그래머를 고용한다.

 - 이를 위해 프로그래머는 이해관계자가 기능 명세서나 요구 사항 문서를 구체화 할 수 있도록 돕는다.

 - 그리고 이해관계자의 기계가 이러한 요구 사항을 만족하도록 코드를 작성한다.

 

2. 아키텍처

 - 소프트웨어의 두 번째 가치는 Software라는 단어와 관련이 있다.

 - 소프트웨어의 단어는 부드러운 + 제품 이라는 단어의 합성어로 제품은 상품을 뜻하고 부드러운 안에 두 번째 가치가 포함되어 있다.

 

 - 소프트웨어는 '부드러움을 지니도록' 만들어 졌다. 이는 기계의 행위를 쉽게 변경할 수 있도록 하기 위해서이다.

 => 만약 기계의 행위를 바꾸는 일을 어렵게 만들고자 했다면 우리는 소프트 웨어가 아니라 하드웨어라고 불렀을 것이다!

 

 - 소프트웨어가 가진 본연의 목적을 추구하기 위해선 소프트웨어는 반드시 부드러워야 한다 다시 말해 변경하기

   쉬워야 한다.

  => 이해관계자가 기능에 대한 생각을 바꾸면, 변경 사항을 간단하고 쉽게 적용할 수 있어야 한다.

 

패러다임 개요

 - 패러다임이란 프로그래밍을 하는 방법으로, 대체로 언어에는 독립적이다.

 - 패러다임은 어떤 프로그래밍 구조를 사용할지, 언제 이 구조를 사용해야 하는 지를 결정한다.

 

1. 구조적 프로그래밍

 - 최초로 적용된 패러다임으로서 테이크스트라는 무분별한 점프 ( goto 문장 )는 프로그램 구조에 해롭다는 사실을

   발견했다.

 - 구조적 프로그래밍은 제어흐름의 직접적인 전환에 대한 규칙을 부여한다.

제어 흐름(영어: control flow 또는 flow of control)은 프로그램에서 실행되는 각 구문, 명령어나 
함수가 호출되는 순서를 의미한다. 한편 제어흐름(制御흐름)을 알고리즘에 따른 명령문을 처리할 때
관련 장치들이 연속적으로 작동되는 과정으로 정의해본다면 제어문은 주어진 조건의 결괏값에 따라서
프로그램의 수행 순서를 제어하거나 문장들의 수행 횟수를 조정하는 문장을 가리킨다.

 

2. 객체 지향 프로그래밍

 - 알골 언어의 함수 호출 스택 프레임을 힙으로 옮기면, 함수 호출이 반환된 이후에도 함수에서 선언된 지역 변수가 

   오랫동안 유지될 수 있음을 발견했다.

 - 이런 함수가 클래스의 생성자가 되었고, 지역 변수는 인스턴스 변수, 그리고 중첩 함수는 메서드가 되었다.

   함수 포인터를 특정 규칙에 따라 사용하는 과정을 통해 필연적으로 다형성이 등장하게 되었다.

 - 객체 지향 프로그래밍은 제어 흐름의 간접적인 전환에 대해 규칙을 부과한다.

 

3. 함수형 프로그래밍

 - 람다 계산법의 기초가 되는 개념은 불변성으로 심볼의 값이 변경되지 않는다는 개념이다.

 - 할당문이 전혀 없다는 뜻이다.

 - 함수형 프로그래밍은 할당문에 대한 규칙을 부여한다.

 

생각할 거리

 - 각 패러다임은 프로그래머에게서 권한을 박탈한다. 어느 패러다임도 새로운 권한을 부여하지 않는다.

 - 각 패러다임은 부정적인 의도를 가지를 일종의 추가적인 규칙을 부여한다.

  => 즉, 패러다임은 무엇을 해야할지 말하기보다 하면 안되는 점에 대해 말한다.

 

결론

 - 패러다임의 역사로 얻을 수 있는 이러한 교훈은 아키텍처와 어떤 관계가 있을까?

우리는 아키텍처 경계를 넘나들기 위한 매커니즘으로 다형성을 이용한다.
우리는 함수형 프로그래밍을 이용하여 데이터의 위치와 접근 방법에 대한 규칙을 부여한다.
우리는 모듈의 기반 알고리즘으로 구조적 프로그래밍을 사용한다.

 - 세 가지 패러다임과 아키텍처의 세가지 큰 관심사 ( 함수, 컴포넌트 분리, 데이터 관리 ) 가 어떻게 서로 연관되는지 보자!

 

---

 

클린 아키텍처 - YES24