인프런 커뮤니티 질문&답변

이미 익숙한 분야를 다룰 때는 당연히 기존의 경험이나 지식이 도메인 설계에 영향을 줍니다. 이미 작동하는 비즈니스가 있는 경우가 아니라, 새로운 서비스를 구상하고 만들 때는 더욱 그렇죠. 온라인 강의 서비스에서 수강신청과 결제라는 개념은 너무 자연스럽게 연결됩니다. 그 정도로 부담을 가지실 필요는 없습니다.

혼자 도메인을 정리하면 다양한 아이디어가 떠오르기도 하죠. 그래서 개발팀과 기획자, 현업 담당자들과 함께 이야기를 나눌 필요가 있습니다. 그때는 자연스럽게 결제 이야기도 나오지 않을까요? 제가 결제를 도메인 이야기에 넣지 않은 것은 이건 꽤 흥미롭고 복잡한 개념이기 때문에 조금 뒤로 미루기로 결정을 했기 때문입니다. 상용 비즈니스를 만드는데, 그러면 우리는 어떻게 수익을 낼 것인가 이야기는 자연스럽고 당연히 결제까지 이어질 수 있을 겁니다. 그러니 오버엔지니어링이 아닌가 고민하실 필요는 전혀 없습니다.

다만, 결제라는 도메인 개념을 깊이 탐구하려면 꽤 많은 시간을 들이고 고민을 해야 합니다. 이런 경우엔 결제 도메인을 더 연구해볼 수 있을 때까지는, 수강신청후 정해진 조건을 만족하는 경우에 라고 좀 더 추상적으로 일단 이야기해두고 뼈대가 되는 기능을 개발하는 걸 먼저 하는 것이 제 스타일입니다.

이미 실무가 돌아가는 비즈니스의 도메인이 아닌 신규 서비스를 만들 때라면, 복잡한 것은 뒤로 미룬다가 제 방식이긴합니다. 다만 이번 Part 1 강의는 개발 초반 2-3일 정도에 일어나는 일이라서 결국엔 조만간 결제 얘기도 나오는 게 자연스럽겠죠.

안녕하세요, 인프런 AI 인턴입니다. 종운님께서 던진 깊이 있는 질문에 대해 도움이 될 만한 내용을 공유하고자 합니다.

도메인 설계는 실제 경험에서 영향을 받을 수 있습니다. 이것이 반드시 나쁜 것은 아니지만, 지나치게 복잡하게 만들 수 있는 위험이 있습니다. 다음은 도메인 설계 시 경험을 활용하는 방법입니다:

1. 요구사항의 정확한 이해: 먼저 현재 프로젝트에 명확히 무엇이 요구되는지를 파악하는 것이 중요합니다. 요구사항이 명확하지 않으면 경험에 의존할 가능성이 커집니다.

2. 단순성 유지: 경험에서 비롯된 추가적 도메인 요소가 추가되기 전에, 그것이 현재 문제의 해결에 반드시 필요한지 평가합니다. ‘KISS(Keep It Simple, Stupid)’ 원칙을 따르는 것이 도움이 될 수 있습니다.

3. 협업과 리뷰: 동료 개발자나 관련 팀과의 협업을 통해 설계를 검증 받는 과정을 통해 불필요한 복잡성을 줄일 수 있습니다.

4. 지속적인 피드백: 개발 과정에서 끊임없이 피드백을 받고 설계를 수정해 나가는 것이 장기적으로 오버엔지니어링을 방지하는 데 도움이 됩니다.

도메인 설계에 있어 경험을 녹이는 방법은 그 자체로 전문성을 발휘하는 기회가 될 수 있습니다. 하지만 항상 현재 요구사항에 부합하는지를 먼저 고려해야 합니다.

관련 정보를 참고하시기 위해 다음 링크를 추천드립니다:
- DDD와 복잡한 도메인에 대한 접근 방식
- 도메인 설계와 경험 활용에 대한 이전 답변

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.