12/27 TIL 클린 아키텍처 15장~22장

앞쪽이 더 중요한 내용이지만, TIL 을 위해 오늘 읽은 것부터!
남은 휴가 소진을 위해 반차를 내서 많이 읽을 수 있었다.

소프트웨어

소프트(soft)웨어를 만든 이유는 기계의 행위를 빠르고 쉽게 변경하는 방법이 필요했기 때문이다.
소프트웨어를 부드럽게 유지하는 방법은 선택사항(세부사항)을 가능한 많이, 오랫동안 열어두는 것이다.
따라서 세부사항과 정책을 가려내는 것부터 시작하자.
소프트웨어 개발 기술의 역사는 플러그인을 손쉽게 생성하여, 확장 가능하며 유지보수가 쉬운 시스템 아키텍처를 확립할 수 있게 만드는 방법에 대한 이야기다.

개발 초기 세부사항의 예시

* 데이터베이스의 형태, 웹서버로의 전달 방식, 프레임워크, 의존성 주입

아키텍처

아키텍처는 소프트웨어 시스템이 쉽게 개발, 배포, 운영, 유지보수되도록 한다.
이를 위해 세부선택을 가능한 오래 남겨둬야 한다 (시스템 동작이 완성되지 않은 상태일 수도 있다.)
즉, 시스템 동작보다는 프로젝트 성장(개발, 배포, 운영, 유지보수)에 좀 더 방점이 찍혀있다.

아키텍처는 시스템의 유스케이스를 지원하는 구조다. 유스케이스를 중심에 든다.
테스트는 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.

다양한 아키텍처들의 공통된 목표는 관심사의 분리다.
소프트웨어 계층을 분리해서 관심사의 분리를 달성한다.

아키텍처가 제공해야 하는것

• 시스템의 유스케이스 - 시스템의 의도를 드러내자
• 시스템의 운영 - 유스케이스에 걸맞은 처리량과 응답시간을 보장  (어떻게 하는거지?)
• 시스템의 개발 - 각 팀이 독립적으로 행동하기 편하게 (콘웨이의 법칙)
• 시스템의 배포 - 즉각적인 배포를 목표로

콘웨이의 법칙

시스템을 설계하는 조직은, 그 조직의 의사소통 구조와 동일한 구조의 설계를 만들게 된다.

중복 - 아키텍트의 함정

중복은 일반적으로 나빠서 본능적으로 줄이게 되는데 가짜(우발적) 중복을 줄이는 것을 피해야 한다!
비슷하게 반복되는 두 코드 영역이 추후에 각자의 경로로 발전한다면, 중복을 줄인게 오히려 힘들게 할 수 있다.(다시 분리하느라)
수직 분리에서의 중복 - 유스케이스 통합의 유혹을 뿌리치자
수평 분리에서의 중복 - 레코드를 있는 그대로 UI까지 전달하고 싶다는 유혹을 뿌리치자

수준(레벨)

입력과 출력까지의 거리를 말한다. 멀어질수록 높은 고수준 컴포넌트다.
입력과 출력은 중요하지 않은 세부사항
데이터 흐름과 소스코드 의존성이항상 같은 방향을 가리키지 않는다.

고수준은 저수준에 대해 몰라야 한다! (의존성 역전 등을 통해)
저수준읜 고수준의 플러그인 형태가 돼야 한다.

읽기 쓰기(입력 출력)에서 먼 번역 컴포넌트가 더 고수준, 더 변화가 적어야 한다.

정책

정책을 잘 분리해, 동일한 시점에 변경되는 정책이 동일한 수준에 위치하고, 동일한 컴포넌트에 속해야 한다.
정책은 고수준이고, 매커니즘은 저수준이다.

핵심 업무 규칙, 엔티티, 유스케이스

• 핵심 업무 규칙 - 규칙을 자동화하는 시스템(프로그램)이 없더라도 그대로 존재하는 것
• 핵심 업무 데이터 - 핵심 업무 규칙에 필요한 데이터
• 엔티티 - 핵심 규칙과 핵심 업무 데이터는 본질적으로 결합되는데, 그 결합된 객체가 엔티티 (객체지향 언어를 쓸 필요는 없다.
• 유스케이스 - 자동화된 시스템이 사용되는 방법을 설명. 어플리케이션에 특화된 업무 규칙 구현

유스케이스

객체다.
입력 데이터, 출력 데이터, 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함한다.
유스케이스는 사용자 인터페이스까지 기술하지는 않는다.
데이터가 들어오고 나가는 방식은 유스케이스와는 무관하다.

업무규칙은 자신을 제어하는 유스케이스에 대해 아무것도 알지 못한다!
(엔티티의 수준이 더 높다)

안쪽일수록 고수준, 저수준을 모른다.

인터페이스 어댑터

MVC 패턴의 컨트롤러, 프리젠터, 뷰가 모두 여기에 속한다.
데이터를 유스케이스와 엔티티에 편한 형식에서,  데이터베이스나 웹 등 외부 에이전시에게 편한 형식으로 변환해준다.

프레임워크와 드라이버 계층

모든 세부사항이 위치하는 곳이다.

---

참고서적

클린 아키텍처 - 로버트  C 마틴 https://product.kyobobook.co.kr/detail/S000001033082

내 생각

소프트웨어는 변경이 가능해야 유의미하다는 게 요즘같은 GPT에 의한 코드 생성 시대에 더 와닿는 것 같다. AI가 생성해준 코드만 쓰고 이를 세세하기 변경하지 못한다면(원하는 결과가 나올 때까지 계속 재생성을 한다거나..) 소프트웨어의 의미가 없는 것이다.
그리고 큰 프로젝트일수록 이 변경을 유의미하게 하는 것은 코드 조각이 아니라 아키텍처이다. AI가 한번에 프로젝트 전체의 아키텍처 전체를 바꿀 정도의 능력을 갖추더라도, 코드 검수(최소한 테스트가 올바른지, 전체 유스케이스를 잘 검사하고 있는지)는 사람이 해야할 것이다. 변경이 너무 자유로워서 아키텍처가 무의미해지는 시대도 과연 올런지? 

프레임워크 또한 세부사항이라는 것이 인상적이다. 프레임워크가 고유의 아키텍처를 강제한다고 생각했는데, 자체 아키텍처와 프레임워크가 양립하는 방법은 좀 더 공부해봐야 할 것 같다.

책을 읽으면서, 지금 회사 프로젝트에서 내가 분리한 구조가 적절한지 계속 돌아보게 된다.
코드가 복잡해지는 느낌이 들 때는 괜히 아키텍처를 만들겠다고 덤볐나 싶다가도, 관심사 분리의 측면에서는 계층을 아예 분리를 안하는 것보다는 확실히 잘 하고 있다는 생각이 든다.