[서평] Clean Architecture

1.  CleanArchitecture의 Clean

클린 아키텍처에서 Clean이란, A 모듈이 B 모듈에 의해 영향을 받지 않는 상태를 의미하는 것 같습니다. 종종 "오염되었다"(Clean의 반대말인 contaminated)라는 표현을 통해 이를 유추할 수 있었습니다. 책에서는 객체지향 관점에서 코드를 깨끗하게 작성하는 방법에 대해 이야기했지만, 제가 생각하는 클린 아키텍처의 Clean과는 거리가 있어 보였습니다. 로버트 C. 마틴(저자)이 말하는 클린 아키텍처의 Clean은 모듈 간 경계가 완전히 분리된 이상적인 상태를 뜻합니다.

(제가 생각한 CleanArchitecture란 모듈 수준의 분리를 의미하는 줄 알았습니다. 따라서 하나의 방법론이라고 이해하고 있었습니다.)

2.  Entity

이번에 새롭게 알게 된 개념 중 하나는 엔티티(Entity)입니다. 엔티티는 도메인 로직을 가질 수 있다고 설명되어 있습니다. 이는 도메인에 특화된 로직을 엔티티를 통해 실행함을 의미합니다. 그렇다면 객체 간 소통과 관련된 로직은 어떻게 해결해야 할까 고민이 생겼습니다. 이 문제를 해결하는 방법으로는, UseCase를 통해 적절히 엔티티를 조합하거나, 특정 디자인 패턴을 활용해 엔티티 간 소통을 가능하게 하는 방법이 있었습니다.

 

3.  SRP

SRP에 대해 어렴풋이 알고 있었습니다. 하나의 객체에서는 단일 책임을 가져야 한다. 이러한 말은 하나의 객체를 어디까지 보아야 하고 만약 객체가 커져서 2천자 이상의 line of code 가 쓰여도 이를 하나의 책임을 지니까 상관 없나 라는 생각을 하게 하였습니다. 책에서는 Actor로 이를 분리하였습니다. 하나의 액터가 단일의 객체에서 책임을 져아한다는 가르침을 받았습니다. 

 

 

4.  다시 보는 CleanArchitecture

클린아키텍쳐의 효용에 대해서 고민해 보았습니다. 언제 클린아키텍쳐를 쓰면 좋을까?라는 질문에 답은 두가지로 결론내렸습니다.

- "1. 변경 가능성이 있는 모듈"

- "2. 협업할 때 "

클린아키텍쳐의 장점인 유연성은 너무나 많은 개발 비용을 할애하게 됩니다.(주니어 개발자 기준) 혼자 MVP프로젝트를 하는 경우 모든 케이스를 생각하면서 추상화 및 구현이 오히려 개발 속도를 저해할 수 있다고 생각했습니다. 이것이 클린아키텍쳐가 갖는 유일한 단점 이라고 생각합니다. 그럼에도 불구하고 사용하고 싶다면 1번 특성인 변경가능성에 대해 검토하면 좋을 것 같습니다. 인터페이스 기반으로 코드들이 활용되고 교체된다는 점에서 매우 생산성을 높일 수 있습니다. 위와 같은 예로서 A, B 유저가 다른 그룹에 속해있고 둘은 추상화 관점으로 완전하게 똑같은 Input을 던지지만 output이 다른 경우가 존재할 수 있습니다.(혹은 outputflow 분기가 바뀐다던지 등등) 이럴경우 의존성 역전의 법칙을 활용해서 유연한 구조를 가질 수 있게 만들 수 있습니다. 

 

 

찐 후기

CleanArchitecture를 잘못 이해하고 있었지만, 어느정도 다시 이해할 수 있어서 좋았습니다. 특히 SOLID를 다시 생각할 수 있었던 것 같습니다.