코드 말고도 데이터나 스키마도 없어지거나 변경될 수 있는지 생각하는 편입니다
- DB 스키마, 프로토콜(REST API 같은), 기능 세 가지 분류 중 코드가 어디에 해당하는지 생각합니다. 스키마와 프로토콜은 필연적으로 회사 내부의 코드나 외부에 전파되기 때문에 나중에 바꾸려면 혼자 며칠만에 해결할 수 없고 협업이 필요하게 됩니다. 따라서 설계 단계에서 시간을 좀 더 씁니다
- 코드가 다루는 데이터의 라이프사이클과 휘발성을 생각합니다. winterjung님께서 고민하시는 서비스가 없어질때의 상황도 포함이 될 것 같네요. OLTP에서 얘기하는 원장, 거래, 이력 테이블 분류도 이런 고민을 시작해보는 방법이 될 수 있을 것 같습니다
데이터에 대한 내용도 넣고 싶었는데 잘 떠올리기 어렵더라구요. 크리티컬한 부분이라 쉽게 건드리기 어렵고 자칫 마이그레이션 지옥에 빠질 수도 있어서 조심스러웠습니다.
말씀하신 것처럼 처음 설계 단계가 매우 중요한 것 같은데요, RAW를 최대한 잘 쌓게 만드는 것이 핵심일 것 같습니다. 아니면 이벤트 소싱 아키텍처가 삭제라는 측면에선 유리할 수 있겠네요. 물론 해당 아키텍처를 제대로 써본 적이 없어서 정말 유효할지는 잘 모르겠습니다.
글 잘 읽었습니다. 조직의 스테이지에 따라 무엇이 이른 최적화고 오버엔지니어링이냐도 달라지는 듯 해요. 어차피 다시 짜야할 코드기도 하면서 다시 짤 순간이 올지 안올지도 모르는 코드라는게 어려운 지점이네요. 저는 xxx 서비스, 기능이 없어진다 했을 때 yyy 코드, 데이터는 어디에 있는게 적절한가? 라는 질문으로 판단할 때도 있는데 다른 분들의 방법도 궁금하네요.