Skip to content
Merged
Show file tree
Hide file tree
Changes from 2 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,29 @@
## Summary

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

## Review

- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3831102227
- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3841314191

### Review content 1

에릭 에반스의 도메인 주도 설계가 등장한다.
이 책을 읽어 봤으므로 어떤 방향으로 데이터베이스를 나눠야 하는 것인지 이해가 조금은 된다.

주의할 점은 이 책에서는 경계 콘텍스트로 번역했지만
도메인 주도 설계의 번역은 제한된 콘텍스트라는 점이다.

출판사, 번역가가 다르다 보니 이런 일이 생기는 건데
헷갈려 하지 말고 원어인 bounded context를 기억하고 있는 것이 좋다고 본다.

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

### Review content 2

용어: synonym

아마 오라클 데이터베이스를 쓸 때 알았을 수도 있지만, 현 시점에서는 처음 들어보는 용어이다.
AI에게 물어보거나 검색해 보면 어떤 용도로 쓰는지 다시 복습할 수 있다.
핵심 개념은 다른 데이터베이스를 참조하거나 다른 서버의 데이터베이스를 참조해서 쓰고 싶을 때 정의해서 사용하는 것이다.
Comment thread
jongfeel marked this conversation as resolved.
Outdated
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
## Summary

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

## Review

- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3831102227
- https://github.com/jongfeel/BookReview/issues/1612#issuecomment-3841314191
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

7장(Service Granularity) 리뷰 파일에 6장(Pulling Apart Operational Data)의 리뷰 코멘트 링크(issue/1612)가 포함되어 있습니다. 이 파일의 주제인 7장 리뷰에 해당하는 issue/1615의 코멘트 링크로 수정하여 내용의 일관성을 높이는 것을 제안합니다.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I missed it.


### Review content 1

객관적 기준의 필요

이 챕터에서도 서비스 분해, 통합에 대해 주관적인 관점이 들어 있기 때문에 서비스를 분해하거나 합치는데 어려움이 있다고 했다.
이전 챕터에서도 느낀 부분이지만 7장의 설명도 참 체계적이고 쉬우면서 객관적인 데이터를 볼 수 있게 하는 좋은 가이드를 준 것 같다.
분석 후 객관적인 데이터를 통해 서비스를 분해할지 합칠지에 대한 결정을 하는 건 참으로 아키텍처 결정을 하는데 있어서 올바른 결정이라고 본다.

### 논의 주제

서비스 세분도의 분해인, 통합인의 쉽고 이해할 수 있는 설명에 감동받아
과거 서비스의 세분도를 떠올려 봤을 때 이 책에서 설명한 분해인, 통합인에 해당됐던 것들이 있는지 얘기해 보면 좋을 것 같습니다.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

서로 다른 경로의 화면이지만 겹치는 로직 (공통 코드) 이 많고 레이아웃이 똑같아서 같은 서비스로 묶어서 개발했다가

기능이 복잡해짐에 따라 각 화면별 예외처리가 늘어나면서 결국 거대 모놀리스 덩어리가 된 적이 있습니다

지금 돌이켜보니 한두개의 통합인만 바라보고 통합하면 나중에 피본다는 귀중한 경험을 했네요


저의 경우는 인프라 관련 횡단 기능인 API 공통 로직에 비즈니스적인 요구사항의 기능을 조금씩 넣었고 그걸 계속 하나의 서비스로 유지했다가 나중에 분리하려고 하면서 이 책에서 설명하는 경계 콘텍스트를 나누지 못해 결국 분리를 하지 못한 경험이 있습니다.
Comment thread
jongfeel marked this conversation as resolved.
Outdated
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

책에 있는 모든 세분도 분해인을 직간접적으로 경험을 해보았는데, 그 중 일부만 소개드리면 아래와 같습니다


이전에 라이더 도메인 서버를 만들면서, 라이더의 배달을 전담하는 서버(A)와 라이더의 배달을 제외한 모든 것(정산, 입직, 보험처리, 운영업무 등)을 처리하는 서버(B)를 분리한적이 있었습니다

책에 나와있는 세분도 분해인의 기준으로볼 때, 확장성/처리량, 내고장성 과 관련이 있다고 말할 수 있을거 같습니다

확장성/처리량 의 측면

  1. B의 경우, 배달 외의 모든 도메인을 처리하기 때문에, 도메인 단위 확장을 고려해야 합니다
  2. A는 운행하는 라이더의 수가 늘어날 수록 영향을 받기 때문에, 트래픽 양상이 유동적 입니다. 반면에 B의 경우는 라이더의 운행과 상관없이 특정 도메인의 비즈니스 규칙에 따라 트래픽 양상이 상대적으로 덜 유동적 입니다

내고장성의 측면

  1. A의 경우 실시간적으로 라이더가 배달을 할 때 요청을 받는 서버이고, 이 배달을 무사히 완료하는게 회사의 수익과 직결하기 때문에 매우 크리티컬하다고 볼 수 있습니다. 반면에 B의 경우는 회사 내부 운영자 향 관리 및 외부사와 연동을 목적으로 하기 때문에, 상대적으로 덜 실시간적이고, 덜 크리티컬하다고 볼 수 있습니다. 이처럼 A와 B는 비즈니스 임팩트 측면에서 차이가 있기에 B의 어떤 기능으로 인해서 A가 영향을 받는 다면 비즈니스에 큰 타격을 입을 수 있기에, 내고장성을 고려하여 A,B를 나누었습니다