드디어 이 책의 메인 이름인 아키텍처라는 부분이 나온다.

사실 본문에서 내용하는 바는 각각 제품의 주기별로 아키텍처를 지원해 좋은점들을 나열한다.

• 개발
• 배포
• 운영
• 유지보수

기본적으로 한가지의 프로젝트가 가지게 되는 사이클이 아닐까 생각한다.

훌륭한 아키텍터는 위와 같은 주기 내에서 알맞은 시점에 알맞은 분리와 설계로 최소한의 비용과 기간으로 주기를 순환 할 수 있도록 하는 목적을 가진다.

Boundaries: Drawing Lines

해당 파트에서는 소프트웨어 아키텍처는 선을 긋는 기술이라고 이야기 한다.

사실 이 부분에서 2가지를 느낄 수 있었다.

• 컴포넌트를 나누고 그 관계에서 의존성을 관리하고 그로인해 얻을 수 있는 안정성
• 의존해야하는 라이브러리를 추후에 결정하며, 잘 그어진 선 덕분에 쉽게 변경할 수도 있다는 점.

먼저 FitNesse 예시를 들었다.

1. 데이터베이스와 앱 사이에 경계선을 그어 앱은 관련 메소드 이외에는 데이터베이스에 대해서 접근할 수 있는 구조를 만들었다. 데이터베이스에 대해 알 수 없으며, 이는 즉 의존성을 제거했다는 의미로 볼 수 있다. 의존성이 없어지면서 데이터베이스를 수정하더라도 앱에 영향을 미치는 경우는 드물게 된다. 즉 매우 안정적인 상태로 들어 갈 수 있게 되었다.
2. 데이터베이스를 쉽게 변경할 수 있게 되었다. mysql을 사용하던 mongo db를 사용하던 그 결정을 나중으로 미룰 수 있게 되었다. 이로 인해 먼저 앱의 기능들을 구현한 후 그에 적합한 데이터베이스를 선택할 수도 있게 된다.

사실 이 부분에서 이 책을 읽으면서 가장 크게 생각하게 된 점을 마주하게 됐다.

기존에 어떤 서비스나 프로젝트에 대해서 고민하기를 어떤 라이브러리에 의존할까? 로 시작했었다.

지금 보면 큰 오류로 생각이 되는 부분인데, 어디에 의존을 하거나 편하게 쓰려고 고민하기 보단 재사용성, 유지보수성들을 고려해 만들게 될 컴포넌트의 구조를 설계하고 구현하는 것이 소프트웨어 개발자 입장에서는 더 높은 우선순위를 지닌다는 것을 알 수 없었다.

Screaming Architecture

: 소프트웨어의 아키텍처는 유스케이스를 지원하는 구조이다.

UseCase란 실제로 사용하기 위한 기능이며, 아키텍처의 목적이기도 하다.

아키텍처는 프레임워크로부터 제공받아서는 안되며, 준수해야 할 사항이 아니다.

이를 나의 실무와 연관지어보면

나는 iOS 개발자이며, iOS 프레임워크 아래에서 개발을 하게 된다. iOS 프레임워크에서 개발을 한다고 해서 앱 컴포넌트의 아키텍처를 iOS에 의존해서 되겠는가?

프레임 워크 역시 앱을 개발하기 위한 한가지의 컴포넌트이며, 또 한가지의 도구일 뿐 그곳에 의존해서는 안된다. 라고 생각을 하게 되니 많은 생각을 할 수 있었다.

또 이 아키텍처의 중심은 UseCase를 위해 그곳으로 기준이 되어 있어야 함을 잊어서는 안되겠다.

Clean Architecture

드디어 이 장에서 클린아키텍처가 무엇인지 설명해준다.

클린 아키텍처란 내부는 고수준/변형성이 적은 구조부터 점점 저수준/변형성이 높은곳으로.

의존성은 안쪽을 향하는 아키텍처의 구조이다.

위의 의존성 관계 즉, 클린 아키텍처를 지키는 것은 가장 비용 절감적일 것 이며, 좋은 아키텍처를 지니는 것이라고 이야기 한다.

이전에 배워왔던 DIP 등의 개념들을 이해한다면 아래와 같은 구조를 쉽게 이해할 수 있다.

안쪽으로 갈 수록 높은 수준/변하기 어려운 것으로 이루어 지고 밖으로 갈 수록 그의 반대이다.

물론 서비스에 따라 원의 개수는 줄어들 수 있다고 생각 한다.

하지만 나는 아래와 같은 기준으로 나뉘어야 하지 않을까 생각한다.

1. 불변성의 수준
2. 의존하는 관계가 안쪽으로 흐르는 것
3. 조금 더 아키텍처에서 서비스적으로 중요한 정책을 가지고 있는 것.

위의 기준대로 또 앞서 말한 여러 원칙들을 통해 얼마나 잘 분리하는 것이 클린 아키택처이다.

Detail

저자가 말하는 세부사항은 클린 아키텍처 구조에서 가장 밖의 부분에 위치해야하는 구조물이다.

가장 변동사항이 많으며, 그저 UI와 비슷하게 제품의 핵심적인 구조물 보단 입출력 장치와 같은 구조물이다.

Database

데이터 베이스는 단순히 데이터를 장기적으로 보관해두는 도구.

Web

웹은 단순히 기능들을 표시하는 출력하는 도구

Framework

단순히 어플리케이션들을 빠르게 제작할 수 있는 도구

위의 모든 요소들은 단순히 도구에 지나지 않는다. 아키텍처의 목표를 실제로 이루는 부분은 아니라는 것이다.

웹으로 표현하던 것을 모바일 앱으로 바꾸싶을 때도 있고.

더 좋은 프레임워크가 나와 바꾸고 싶을 때도 있고.

다루는 데이터들의 성격이 더 방대해지거나 변경이 되어 더 이상 RDB가 필요하지 않을 수도 있다.

아키텍처의 핵심적인 기능들이 이에 의존하게 된다면 그 뒤의 변경에선 말하지 않아도 될 것이다.

Clean Architecture 후기

사실 이전부터 좋은 구조를 설계해야하고 그런 필요성에 대해서 생각만 했었지 직접적으로 어떻게 해결하려는 액션이나 스터디를 해본적이 없었다.

그러므로 이 책이 내 아키텍처에 대한 첫 고민이라 할 수 있다.

사실 읽으면서 아직 길지 않은 개발 경험 때문인지 실로 공감이 가지 않거나 명확히 이해하지 못하는 부분들도 여럿 있었다. 워낙 내용 자체가 추상적이기도...

그러나 배운 부분에 있어서는 명확하고 앞으로 좋은 코드에 있어서 바라보아야 할 방향성을 짚어준 것에 대해서는 확실하다.

1. 코드를 분리할 것.
2. 변할 수 있는 것들과 변하지 않는 것으로 나눌 것.
3. 변할 수 있는 것들이 변할 때, 변하지 않는 것에 영향을 주지 않을 것.
4. 그 방법은 추상화를 통한 의존성에 대한 역전으로.

위의 배움들로 조금 더 생각을 해보면 앞으로의 코드에 많은 변화들을 줄 수 있지 않을까.

아마 몇개의 프로젝트 뒤에 더 읽어본다면 더 많은 내용들이 보일 수 있을 것 같다.

아는 만큼 보이고 경험한 만큼 배울 수 있는 책인 것 같다.