Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
## Summary

- https://github.com/jongfeel/BookReview/issues/1588

## Review

- https://github.com/jongfeel/BookReview/issues/1588#issuecomment-3754714597

### Review content

에드워드 요던과 래리 콘스탄틴은 항상 아키텍처와 설계 얘기가 나올 때 빠지지 않는 것 같다.
Structured Design은 정말 고전인데 책을 구해보려고 했으나 이젠 살 수도 없는 책이다.
구할 수 있다면 정말 읽어보고 싶은 책이다.

---

여기서 나온 평가 지표들은 과거에 읽었던 책에서도 언급된 내용들이다.
그래서 링크를 달아본다.

1.
소프트웨어 아키텍처 101 에 거의 동일한 내용이 chapter 3 모듈성 부분에 나온다.
3.2.2 커플링
3.2.3 추상도, 불안정도, 메인 시퀀스로부터의 거리
3.2.4 메인 시퀀스로부터의 거리
내용을 거의 복붙해 놨다.

- https://github.com/jongfeel/BookReview/issues/398

2.
로버트 마틴 본인의 저서인 클린 아키텍처 14장 컴포넌트 결합 부분에 매우 자세하게 설명하고 있다.

- https://github.com/jongfeel/BookReview/issues/366

---

하나 감상평을 더 추가해보자면
과거에 로버트 마틴의 책을 읽어 봤을 때는 그렇게 대단하다고 느끼진 못했는데
이후 출판되는 좋은 책들에서 로버트 마틴을 많이 언급한 걸 볼 때마다
많은 업적을 이뤘고 후대에 나오는 책에도 참조되는 걸 보면
보통 분은 아니라는 생각과 소프트웨어에 대한 다른 시각을 가졌다는 점을 다시 돌아보게 된다.
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
## Summary

- https://github.com/jongfeel/BookReview/issues/1593

## Review

- https://github.com/jongfeel/BookReview/issues/1593#issuecomment-3772706068
- https://github.com/jongfeel/BookReview/issues/1593#issuecomment-3777514740

### Review content 1

네임스페이스 구성을 보고 내가 이전 프로젝트에서 만들었던 네임스페이스가 별로라는 생각이 들었다.

나의 경우는 interface와 class를 별도의 네임스페이스로 분리했고 계층 구조는 책의 설명대로라면 컴포넌트에 해당하는 리프 노드를 interface로 선택했었다.

- ss.login
- ss.login.interfaces

이렇게 한 이유는 login에 관련된 인터페이스를 ss.login.interfaces 라는 네임스페이스에 한꺼번에 관리하고
디펜던시는 ss.login이 아닌 ss.login.interfaces를 참조하게 했다.
즉, 처음부터 다른 컴포넌트들은 구상 클래스의 접근을 막고 인터페이스만 참조하고 호출해서 사용하는 식으로 했었고, 이게 합리적이라는 생각을 했었다.

---

이제 이 책의 설명대로라면 리프 노드는 컴포넌트여야 하고, 상위는 루트 네임스페이스여야 하므로 ss.login.interfaces와 같은 네임스페이스를 사용하지 말아야겠다.
그리고 이렇게 해야 앞으로 이 책의 훌륭한 설명과 가이드에 따라 의존성 관리나 아키텍처 구조 잡을 때 좋을 것 같다는 생각이 든다.

### Review content 2

컴포넌트 기반 분해 패턴에 대한 추가 리뷰

나는 C#의 네임스페이스를 사용하므로 여기에서 설명하는 네임스페이스에 대한 이해도가 상당히 높다고 볼 수 있고, 내용을 읽으면서도 내가 설계했던 네임스페이스 체계에 대해서 다시 생각해 보게 되는 계기가 되었다.

사실 내가 여태까지 했던 건 기능적으로 잘 동작하고 호출하고 응답을 받을 수 있도록 설계하는게 더 중요하다고 생각해서 네임스페이스 구조에 대해서는 깊게 생각해 보지 않았는데, 여태까지 읽었던 아키텍처 관련 내용 중에는 이 챕터의 내용이 매우 현실적이고 구체적이며 실용성이 있다는 생각이 든다.

현실적인 건 그냥 커다란 똥덩어리(여기서의 표현으로는 진흙잡탕)를 잘게 분해하기 부터 시도하면 안된다는 것이다. 이건 내가 실제로 해봤기 때문에 그렇게 하면 안된다는 걸 뼈저리게 느낀다. 분해 및 리팩터링을 할 거면 제대로 해야 하는데 그걸 설득시킬 자료가 여태까지 없었기 때문이다. 그나마 있던 자료는 로버트 마틴의 클린 아키텍처에서 컴포넌트 흐름에 대한 설명 정도 였기에 이 챕터의 내용은 상당히 유용하다고 볼 수 있다.

또 구체적인 건 그냥 이렇게 잘 하면 된다가 아니라 내용이 중복되더라도 점진적으로 진행되는 내용에 대해 잘 설명하고 있다는 점이다. 더 구체적으로는 사가의 대화 내용인데 지어낸 얘기 같지 않다는 점이 좋다.

마지막으로 실용성이 있는 부분은, 정말 컴포넌트 기반으로 분해를 하는 방법에 대해 여섯 단계로 잘 설명하고 있고 그 방법도 잘 나와 있으므로 앞으로 어떤 서비스 단위의 분해 방법이 필요하다고 하면 여기에 소개된 방법을 쓰면 좋을 것 같다.

## 논의 주제

처음부터 모놀리스는 아니더라도 컴포넌트 기반으로 분석 과정을 통해 하나의 서비스를 완성해 나가는 기법에 대해 설명한 부분이 인상 깊었다. 솔직히 어려울 수도 있는 내용을 구체적이고 자세히 잘 설명할 수 있다는 점에서 감동까지 받았다.

꼭 여기에서 설명하는 컴포넌트 분해 기법이 아니더라도 자신이 설계한 컴포넌트의 네임스페이스 설계가 책에서 설명하고 있는 방법에 비춰 봤을 때 어느 정도 수준인지 논의해 보면 좋을 것 같다.
(책의 예시대로라면, 골프공? 농구공? 비행기?)

나의 경우에는 농구공 두 개, 여러개의 골프공 정도라고 볼 수 있는데, 레이어드 아키텍처를 버리지 않고 살리면서도 컴포넌트 기반 네임스페이스를 사용한 경우가 있기 때문이다.
여기서 농구공에 해당하는 부분은 첫 번째 리뷰 내용에 있듯이 네임스페이스 규칙에 대해 책의 방법이 아닌 내가 하고 싶은 방법대로 했다는 점이다. 어떻게 보면 네임스페이스 별 컴포넌트 이지만 그 안에는 레이어드 구조를 살리고 싶었던 미련이 있었다고 볼 수 있다.