[책 정리] 25. 계층과 경계 - Clean Architecture

 

-

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다.

몇몇 단순한 시스템에서는 이 정도로 충분하다.

하지만 대다수의 시스템에서 컴포넌트의 개수는 이보다 훨씬 많다.

 

 

 

움퍼스 사냥 게임

 

 

 

클린 아키텍처?

 

 

 

흐름 횡단하기

 

 

 

흐름 분리하기

 

 

 

결론

 

-

아키텍트로서 우리는 아키텍처 경계가 언제 필요한지를 신중하게 파악해내야 한다.

또한 우리는 이러한 경계를 제대로 구현하려면 비용이 많이 든다는 사실도 인지하고 있어야 한다.

이와 동시에 이러한 경계가 무시되었다면 나중에 다시 추가하는 비용이 크다는 사실도 알아야 한다.

포괄적인 테트스 스위트(test suite)가 존재하고 리펙터링으로 단련되었더라도 마찬가지다.

 

 

-

추상화가 필요하리라고 미리 예측해서는 안 된다.

이것이 바로 YAGNI(You Aren't Going to Need It)가 말하는 철학이다.

오버 엔지니어링(over engineering)이 언더 엔제니어링(under engineering)보다 나쁠 때가 훨씬 많기 때문이다.

다른 한편으로 어떤 아키텍처 경계도 존재하지 않는 상황에서 경계가 정말로 필요하다는 사실을 발견한 경우, 그때서야 경계를 추가하려면 비용이 많이 들고 큰 위험을 감수해야 한다.

 

 

-

소프트웨어 아키텍트여, 당신은 미래를 내다봐야만 한다.

당신은 현명하게 추측해야만 한다.

당신은 비용을 산정하고, 어디에 아키텍처 경계를 둬야 할지, 그리고 완벽하게 구현할 경계는 무엇인지와 부분적으로 구현할 경계와 무시할 경계는 무엇인지를 결정해야만 한다.

 

하지만 이는 일회성 결정은 아니다.

프로젝트 초반에는 구현할 경계가 무엇인지와 무시할 경계가 무엇인지를 쉽게 결정할 수 없다.

대신 지켜봐야 한다

시스템이 발전함에 따라 주의를 기울여야 한다.

경계가 필요할 수도 있는 부분에 주목하고, 경계가 존재하지 않아 생기는 마찰의 어렴풋한 첫 조짐을 신중하게 관찰해야 한다.

 

 

-

첫 조짐이 보이는 시점이 되면, 해당 경계를 구현하는 비용과 무시할 때 감수할 비용을 가늠해 본다.

그리고 결정된 사항을 자주 검토한다.

우리의 목표는 경계의 구현 비용이 그걸 무시해서 생기는 비용보다 적어지는 바로 그 변곡점에서 경계를 구현하는 것이다.

목표를 달성하려면 빈틈없이 지켜봐야 한다.