▲
savvykang 2024-10-14 | parent | ★ favorite | on: 소프트웨어 파괴의 미학 - 불확실성에 대항하는 방법(kciter.so)

코드 말고도 데이터나 스키마도 없어지거나 변경될 수 있는지 생각하는 편입니다

  1. DB 스키마, 프로토콜(REST API 같은), 기능 세 가지 분류 중 코드가 어디에 해당하는지 생각합니다. 스키마와 프로토콜은 필연적으로 회사 내부의 코드나 외부에 전파되기 때문에 나중에 바꾸려면 혼자 며칠만에 해결할 수 없고 협업이 필요하게 됩니다. 따라서 설계 단계에서 시간을 좀 더 씁니다
  2. 코드가 다루는 데이터의 라이프사이클과 휘발성을 생각합니다. winterjung님께서 고민하시는 서비스가 없어질때의 상황도 포함이 될 것 같네요. OLTP에서 얘기하는 원장, 거래, 이력 테이블 분류도 이런 고민을 시작해보는 방법이 될 수 있을 것 같습니다
▲
kciter1 2024-10-14  [-]

데이터에 대한 내용도 넣고 싶었는데 잘 떠올리기 어렵더라구요. 크리티컬한 부분이라 쉽게 건드리기 어렵고 자칫 마이그레이션 지옥에 빠질 수도 있어서 조심스러웠습니다.

말씀하신 것처럼 처음 설계 단계가 매우 중요한 것 같은데요, RAW를 최대한 잘 쌓게 만드는 것이 핵심일 것 같습니다. 아니면 이벤트 소싱 아키텍처가 삭제라는 측면에선 유리할 수 있겠네요. 물론 해당 아키텍처를 제대로 써본 적이 없어서 정말 유효할지는 잘 모르겠습니다.

답변달기