brunch

매거진 40대 개발자의 일기

라이킷 10 댓글 1

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 에디의 기술블로그 Jan 23. 2022

[서평] 만들면서 배우는 클린 아키텍처

새해가 되어 처음 읽은 책은 "만들면서 배우는 클린 아키텍처" 라는 책입니다. 140페이지 분량으로, 출퇴근길에 들고 다니면서 편하게 읽을 수 있는 가벼운 책입니다. 여유로운 주말에 책을 읽고, 가벼운 마음으로 서평을 남겨봅니다. 서평은 개인적인 생각으로 작성하였으니 부디 참고만 해주세요. 서로 생각이 다를 수 있으니, 제 의견은 참고만 해주시고, 직접 구매해서 책을 읽어보시길 바랍니다."

http://www.yes24.com/Product/Goods/105138479

만들면서 배우는 클린 아키텍처 - YES24

우리 모두는 낮은 개발 비용으로 유연하고 적응이 쉬운 소프트웨어 아키텍처를 구축하고자 한다. 그러나 불합리한 기한과 쉬워보이는 지름길은 이러한 아키텍처를 구축하는 것을 매우 어렵게

www.yes24.com

1. 책을 읽은 소감

이 책을 읽으면서 느낀 점에 대해서 말해보겠다.

클린 아키텍처 & 육각형 아키텍처

"클린 아키텍처"란 로버트 C. 마틴의 아키텍처 이론인데, 이 책은 "클린 아키텍처"를 자바&스프링 기반의 육각형 아키텍처 기반의 샘플 코드로 설명한다. 이론 중심의 책이 아닌, 샘플 코드 중심의 책이라서 이론적인 내용은 많이 부실하다. 이 책을 읽은 개발자는 반드시 로버트 C. 마틴 의 "클린 아키텍처"를 읽어보길 바란다.

http://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24

살아있는 전설이 들려주는 실용적인 소프트웨어 아키텍처 원칙『클린 코드』와 『클린 코더』의 저자이자 전설적인 소프트웨어 장인인 로버트 C. 마틴은 이 책 『클린 아키텍처』에서 이러한

www.yes24.com

이 책에서 개발자에게 계속 질문하는 주제는?

이 책에서는 끊임없이 아래와 같이 질문한다.

"클린 아키텍처는, 유지보수 가능한 소프트웨어를 만드는 데 어떻게 도움이 될까?"

만약 이 책을 읽는 개발자가 "클린 아키텍처"를 도입해서 오히려 소프트웨어가 더 복잡해지고 유지보수하기 어려워진다면, "클린 아키텍처"를 잘못 이해한 것이다. "클린 아키텍처"에 집중하기 전에, 유지보수 가능한 소프트웨어를 어떻게 만들 수 있을지 먼저 고민을 해보자.

의존성

"클린 아키텍처"에서 가장 중요한 키워드는 무엇일까? "클린 아키텍처"의 저자인 "로버트 C. 마틴"은 어떻게 생각할지는 모르겠지만, 내가 생각하는 키워드는 바로 "의존성"이다.

의존성!!

소프트웨어를 계층으로 분리하고, 동심원으로 표현할 수 있다. 이때, 동심원에서 의존성은 반드시 원 안쪽으로 향해야 한다. 내부의 원에 속한 요소는 원 밖의 외부의 어떤 것도 알지 못한다.

도메인 주도 설계

"클린 아키텍처"는 "도메인 주도 설계"와 매우 밀접한 관련이 있다. 이 책에서는 "도메인 주도 설계"에 대해서 많은 얘기를 한다. 사실, "도메인 주도 설계"는 책 한 권으로 전부 설명하지 못할 만큼 너무 방대한 주제이다. 비록, 이 책은 "도메인 주도 설계"의 "전술적 설계"의 극히 일부에 대해서만 설명하므로, "도메인 주도 설계"에 대해서 깊게 배울 수 있는 책은 아니다. 그래도, 이 책은 도메인 주도 설계를 공부하는 누군가에게는 꽤 도움이 될 것이다.

소프트웨어에 정답이 과연 존재할까?

소프트웨어는 정답이 없다. 소프트웨어는 소프트하며, 하드하지 않다. 소프트하다는 의미는, 변경이 잦고, 변경에 따른 유연한 대응이 필요하다. 원칙만을 강조하면서 정답만을 강요할 수는 없다. 가이드라인(기준)이 필요하며, 개발팀에서 가이드라인에 맞게 최적의 소프트웨어를 구현해야 한다.

참 어려운 주제이다..

2. 그동안 풀지 못한 숙제에 작은 힌트를

이 책을 읽고, 그동안 해결하지 못한 문제들에 대한, 작은 힌트를 얻게 되었다.

JPA 엔티티, 도메인 엔티티

작년에 필자가 "도메인 주도 설계"를 공부하면서 가장 어려웠던 주제는 아래와 같다.

"JPA 엔티티"와 "도메인 엔티티"를 같은 클래스로 정의할 것인지?

아니면 별도의 클래스로 분리할 것인지?

일단, "JPA 엔티티"와 "도메인 엔티티"가 어떤 차이가 있는지 모르는 개발자가 꽤 많다. 심지어는 JPA 엔티티를 도메인 엔티티로 같은 단어로 사용하는 개발자가 매우 많다. 차이를 모르겠다면, "도메인 주도 설계"를 공부하길 바란다.

아무튼, 나는 이 주제에 대해서 스프링 커뮤니티에 질문을 남겼는데, 개발자의 의견은 다양했다.

1. 같은 클래스로 한다.

2. 별도의 클래스로 한다.

3. 차라리 JPA를 사용하지 않겠다.

4. 그때그때 다르다.

이 책의, 8장을 읽어보면, 이 주제에 대해서 작은 힌트를 알려준다. 각자 읽어보길 바란다.

"도메인 주도 설계" 시 단위 테스트 작성에 대한 인사이트

단위 테스트는 도메인 엔티티에 녹아있는 비즈니스 규칙을 검증하기에 가장 적절한 방법인데, 이 책에서 잘 설명하고 있다. 그동안 단위 테스트 작성의 범위를 어떻게 정하면 좋을지 어려움이 많았는데, 이 책을 통해서 조금이나마 단위 테스트에 대한 깨달음을 얻게 되었다.

3. 좋은 책이지만, 아쉬운 점

"클린 아키텍처" 수박 겉핥기

이 책은 "클린 아키텍처"를 샘플 코드와 함께 이해하기 쉽게 설명하지만, 이론을 상세하게 설명하지 않는다.

육각형 아키텍처 == 클린 아키텍처?

"클린 아키텍처"는 "육각형 아키텍처"와 대부분 일치하지만, "클린 아키텍처"가 반드시 "육각형 아키텍처"와 일치하는 것은 아니다. 육각형 아키텍처가 아니더라도 클린 아키텍처를 구현할 수 있을 것이다. 더 많은 아키텍처를 소개해줬으면 좋았을 것이다. 이 책을 읽은 누군가가, 클린 아키텍처를 하겠다고 설레발치면서, 본인의 프로젝트를 전부 육각형 아키텍처로 구축할까봐 걱정된다.

단위 테스트에 대한 의견 차이

단위 테스트는 개발자의 관점에 따라서 견해 차이가 있다. 필자는 최근까지 단위 테스트 작성 시 의존하는 모든 클래스를 목킹해야 한다고 생각했었지만, 최근에 생각이 조금 바뀌었다. 의존되는 클래스를 전부 목으로 교체하지 않아도 단위테스트 라고 부를 수 있다고 생각한다. 아무튼, 이 책에서의 단위테스트 설명이 너무 짧아서 아쉬움이 남는다.

아는 만큼 보일 것이다.

도메인 주도 설계에 대한 개념이 없는 개발자는 일부 샘플 코드를 이해하는데 어려움이 있을 것이다. "도메인 주도 설계"에 대한 각자 경험의 차이에 따라서, 소스 코드가 눈에 보이는 것도 다를 것이다. 아는 만큼 보일 것이고, 아는 만큼 소스코드가 읽힐 것이다. 도메인 주도 설계를 경험한 이후에 나중에 이 책을 다시 읽어보길 바란다.