해결된 질문
작성
·
131
1
안녕하세요! 영호님. 강의 정말 잘 보고 있습니다.
강의에서 도메인을 '소프트웨어로 구현할 요구사항의 범위' 라고 해주셨고, 예시로 들어주신 음식 배달 시스템에서 메뉴, 주문, 결제가 도메인이 되었습니다.
제가 궁금한 점은 다음과 같습니다.
위와 같은 방식으로 도메인을 결정한다면, 인증을 위한 access token, refresh token 등은 도메인에 포함되지 않나요?
이런 기술적 구현체들은 실제 세계에는 없는 개념인데, 관련 모델과 서비스들을 어디에 배치하는 게 좋을까요?
반대로 서비스를 이용할 때 본인인증(kcb와 같은)이 필요한 상황이라면, 실제 세계에서의 신분증 검사 같은 방식의 신원 확인을 대체하는 Verification이라는 도메인이 생성되는 건가요?
물론 정답은 없겠지만, 도메인 모델링에서 기술 구현과 비즈니스 요구사항의 경계를 설정하는 방법에 대한 인사이트를 얻고 싶습니다. 감사합니다!
답변 2
3
dev.taeyoung닌 안녕하세요.
좋은 질문 남겨 주셔서 감사합니다. 🙂
아래에 답변 드립니다.
위와 같은 방식으로 도메인을 결정한다면, 인증을 위한 access token, refresh token 등은 도메인에 포함되지 않나요? 이런 기술적 구현체들은 실제 세계에는 없는 개념인데, 관련 모델과 서비스들을 어디에 배치하는 게 좋을까요?
-> 질문 전에 말씀하신 것처럼 도메인은 "소프트웨어로 구현할 요구사항의 범위"입니다. 실세계에 있는지 없는지는 중요하지 않습니다. 그 문제가 우리가 해결해야 하는 요구사항 범위에 포함된다면 도메인에 포함됩니다. 예를 들어 게임을 만든다면 게임에 등장하는 요소들은 실세계에 존재하지 않는 것들이 많지만 이들은 게임을 만들기 위해서는 우리가 구현해야 하는 대상입니다. 해당 요소가 우리가 해결할 문제 영역에 포함된다면 도메인에 포함된다고 생각하시면 됩니다. 따라서 인증 역시 소프트웨어 안에 코드로 구현되어야 하기 때문에 도메인에 포함됩니다.
아마도 문제의 범위를 정의하는 '도메인'의 개념과 코드를 배치하기 위해 사용하는 '도메인 레이어'의 개념을 혼동하신 것 같아요. 인증이라는 요구사항을 코드로 해결해야 한다면 인증은 우리가 해결해야 하는 문제이기 때문에 도메인에 포함됩니다.
반대로 서비스를 이용할 때 본인인증(kcb와 같은)이 필요한 상황이라면, 실제 세계에서의 신분증 검사 같은 방식의 신원 확인을 대체하는 Verification이라는 도메인이 생성되는 건가요?
-> 본인인증이 필요한 상황이라면 이것 역시 우리가 해결할 문제이기 때문에 도메인에 포함됩니다. 'Verification이라는 도메인'이라고 말씀하신 것은 이번에는 '도메인'과 '도메인 개념'을 혼동하신게 아닌가 싶어요. 신원확인이라는 요구사항을 구현해야 한다면 신원확인을 구현하기 위한 요소들은 우리의 도메인에 포함됩니다. 그 중에서 신원 확인을 위한 도메인 로직이 존재한다면 (도메인의 유형에 따라 정확한 명칭은 다르겠지만) Verification이라는 도메인 개념을 반영하는 도메인 객체가 생성되어야 할 것이고 결과적으로 그에 대응되는 도메인 클래스가 만들어질 것입니다. 그리고 이 클래스들은 도메인 레이어에 배치될 것입니다.
답변이 되었는지 모르겠네요. 🙂
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
dev.taeyeong님께서 ‘오브젝트 - 기초편’ 강의를 통해 많은 도움을 받으셨다니 기쁩니다! 도메인 모델링에서 기술적 구현과 비즈니스 요구사항의 경계를 설정하는 것은 객체지향 설계에서 매우 중요한 부분입니다. 여러분의 질문에 대해 도움을 드리도록 하겠습니다.
Access token이나 refresh token과 같은 인증 관련 구현체는 일반적으로 인프라스트럭처나 기술적 측면에서 다루어집니다. 이러한 요소는 비즈니스 도메인이라기보다는 시스템의 기술적인 요구사항이므로, 도메인 모델에 포함되기보다는 인프라스트럭처 계층으로 분리되어 관리됩니다.
본인 인증(예: 신분증 검사, kcb 인증 등)은 시스템에서 비즈니스 로직을 충족하기 위한 중요한 도메인 개념이 될 수 있습니다. 따라서, Verification이라는 도메인 개념을 생성하여, 비즈니스 로직과 긴밀하게 결합되어야 할 수 있습니다.
도메인 모델의 순수성 유지: 비즈니스 로직과 직접 관련된 개념과 흐름은 도메인 모델 내에서 다루고, 기술적 세부 사항은 가능한 한 인프라스트럭처나 서비스 계층에서 분리하여 관리합니다.
도메인 이벤트 활용: 도메인 로직과 시스템의 기술적 요소 간의 통합은 도메인 이벤트를 사용하는 것도 하나의 방법입니다. 이는 두 영역 간의 결합도를 낮추는 데 이점이 있습니다.
아래 링크들은 유사한 주제를 다루고 있어 추가적인 인사이트를 얻는 데 도움을 줄 수 있을 것입니다:
질문의 핵심은 기술과 비즈니스의 적절한 경계를 설정하여 도메인 로직이 명확하게 유지되도록 하는 것입니다. 각각의 구현체가 비즈니스 요구사항에 관련되어 있는지는 상황에 따라 다를 수 있기에 명확한 분석이 필요합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변 감사합니다 !
제가 강의 내용을 조금 다르게 이해한 것 같네요 ㅎㅎ
아직은 개념들이 조금 헷갈리는 것 같은데, 강의 쭉 보면서 좀 더 이해해보겠습니다.
좋은 강의 감사합니다 !