인프런 커뮤니티 질문&답변
작성자 없음
작성자 정보가 삭제된 글입니다.
도메인에 대한 개인적인 경험이 다음 설계에 영향을 주는 경우가 많습니다. 설계를 하실 때, 이전 경험에서 비롯된 도메인을 어느 정도까지 설계에 반영하시나요?
작성
·
9
0
안녕하세요, 토비님. 아직 부족한 점이 많아 질문을 많이 드리게 되네요.
Section 3에서 소개된 splearn 도메인 설계 강의를 듣기 전에, 스스로 먼저 도메인 모델링을 해보는 시간을 가졌습니다.
그 과정에서 회원, 수강, 강의 등의 개념 외에 수강신청이라는 도메인을 도출했는데요, 그 이유는 “수강은 수강신청 후 결제가 완료되어야 성립된다”는 제 안의 암묵적인 도메인 해석 때문이었습니다.
그런데 사실 강의에서 제시된 사용자 스토리에는 결제라는 개념이 존재하지 않았습니다. 그럼에도 불구하고, 과거 경험에서 비롯된 도메인이 자연스럽게 설계에 스며들었고, 결과적으로 오버엔지니어링으로 이어졌다는 생각이 들었습니다.
이런 식의 ‘의도되지 않았지만 경험에 따른 그럴듯한 도메인’을 설계에 넣고 싶은 유혹은 실제 회사에서 설계할 때도 자주 느끼는 부분입니다.
토비님께서는 이런 상황에서 어떤 기준으로 도메인을 포함하거나 배제하시는지, 그리고 본인의 경험을 어떤 방식으로 설계에 녹이시는지가 궁금해져서 질문드리게 되었습니다!
감사합니다! (_ _)
답변 1
0
안녕하세요, 인프런 AI 인턴입니다.
종운님이 흥미로운 질문을 남겨주셨네요! 도메인 설계에서 개인적인 경험이 영향을 주는 방향에 대해서 말씀주셨는데요, 이전 경험에 기반한 설계는 자연스럽고 때로는 유용할 수 있지만, 오버엔지니어링을 피하기 위해 몇 가지 기준을 세워 놓는 것이 중요합니다:
요구 사항 우선: 설계할 때 가장 먼저 고려해야 하는 것은 명확하게 정의된 요구 사항 및 사용자 스토리입니다. 이는 현재 도메인 모델링의 출발점이 되어야 하며, 여기에서 벗어난 요소들(예: 결제 기능)은 신중히 검토한 후 포함해야 합니다.
검증 가능한 경험: 과거 경험들이 얼마나 현재 프로젝트와 밀접한 관련이 있으며, 실제로 유사한 문제에 대한 해결책이었는지 평가합니다. 경험이 객관적인 데이터나 사용자 피드백에 의해 뒷받침될 수 있다면 설계에 포함할만한 가치가 있습니다.
팀과의 반복적인 피드백: 팀원들과의 협의를 통해 자신의 해석 및 설계가 요구 사항에 적절한지 확인합니다. 여러 관점에서 도메인을 검토함으로써 오버엔지니어링의 위험을 줄일 수 있습니다.
궁극적으로, 도메인 설계는 단순히 이론적인 구조보다 실제 문제 해결에 초점을 맞추는 것이 중요하기 때문에 이러한 방식을 통해 종운님의 설계에 도움이 되길 바랍니다!
감사합니다! (_ _)