인프런 커뮤니티 질문&답변
작성한 질문수
도메인 로직에 대해서 궁금한 것이 있습니다.
해결된 질문
작성
·
185
0
현재 Member 도메인 모델 확장 까지의 수업을 듣고 궁금한 것이 있습니다!
저희가 이번 수업을 포함하여 지금까지 요구사항(도메인) -> 도메인 모델(회원) -> 비밀번호 해시라는 일련의 과정을 통해 비밀번호 암호화와 관련한 도메인 모델의 규칙, 속성, 행위 등을 뽑아냈기 때문에 비밀번호 암호화까지 도메인 로직에 포함된다고 이해했습니다.
<인터페이스 위치를 결정하는 기준에 대해> 해당 답변에서도 PasswordEncoder를 어디에 둘지 결정할 때 사용한 기준은 도메인 모델을 이야기할 때 이게 등장하는가 라고 말씀해주시기도 했고요! 그렇다면 개발은 결국 요구사항을 토대로 진행되는 것이기에 모든 코드가 도메인 로직으로 분류되어야 하는 것 아닌가? 하는 의문점이 생겼습니다! 토비의 생각을 듣고 싶습니다!
답변 2
4
안녕하세요.
어디까지가 도메인의 로직인가라는 기준은 사람마다 조금씩 다를 수 있습니다. 요즘은 예전의 이미 존재하는 오프라인 비즈니스 도메인에 대한 지원 소프트웨어를 개발하는 시절이 아니라 처음부터 온라인 비즈니스로 시작하는 경우가 많은데, 이럴 때는 도메인을 바라보는 관점이 여러가지로 나뉠 수 있습니다.
그렇지만, 일반적으로 요구사항이 도메인 로직은 아닙니다. 보통 요구사항을 누가 정의하느냐에 따라 다르겠지만, 도메인 로직은 그 중에서 이 소프트웨어가 적용되는 사용자의 활동이나 관심사, 비즈니스에서 기업 정책이 바뀌지 않는한 변하지 않는 본질에 더 가까운 것들이라고 할 수 있습니다. 그래서 도메인 전문가와 개발자가 함께 도메인을 이해하기 위한 노력을 통해서 발견되어지는 것들이죠.
반면 고객이나 사용자, 기획자로부터 나오는 요구사항에는 시스템이 무엇을 하는지에 대한 상세한 내용이 담겨있기도 합니다. 본질적인 비즈니스의 규칙이 달라지지 않지만, 종종 UI나 시스템에 반영하는 기술의 종류와 활용 방식은 변경되기도 합니다.
그런 비기능적인 요구사항, 기술, UI와 관련된 디테일을 포함하는 요구사항을 수집하지만, 그 중에서 비즈니스의 잘 변하지 않는 규칙과 특성을 찾아서 그걸 도메인 모델로 만들고, 그 안에 일관되게 적용되는 규칙을 정의해서 도메인 로직을 만듭니다. 보통 도메인 로직을 비즈니스 로직으로도 부릅니다. 이 둘을 구분하기도 하는데, 이건 좀 얘기가 복잡해지니 나중에 기회가 되면 강의에서 설명을 해보겠습니다.
굳이 계층을 분리해서 도메인 모델을 독립적인 코드를 만들려는 노력은 실제로 많은 가치를 줍니다. 사실 헥사고날의 애플리케이션 전체(애플리케이션 계층 + 도메인 계층)를 다 도메인 로직이라고도 합니다. 그래서 좀 헷갈리죠. 이때는 소프트웨어를 환경에 따른 기술과 외부와의 연결이 필요한 요소, 보통 액터라고 불리는 것들과의 상호작용을 배제한 소프트웨어 관점의 도메인(이때 도메인은 지금 관심을 가지는 영역이라는 의미에 가까울 겁니다) 로직이고요. 강의에서 도메인이라고 말할 때는 그보다 더 본질적인 규칙과 개념, 속성을 담은 부분을 도메인 모델, 그리고 그게 반영된 코드가 담긴 도메인 계층이라고 분류한 것입니다.
도메인, 비즈니스, 애플리케이션, 서비스 이런 일상적인 의미로 통용되는 단어는 사실 그걸 사용할 때 매번 명확하게 여기서는 이런 뜻으로 말하는 것이다라는 생각을 해야합니다. 매우 피곤하지만 어쩔 수가 없습니다.
예로 드신 PasswordEncoder에 담긴, 회원의 비밀번호는 암호화를 해서 저장한다, 이게 아마 한 25년 전에 웹 개발을 처음하던 시절에는 도메인으로 취급하지 않았을 겁니다. 개발자를 제외하면 비밀번호 암호화가 뭐고, 이게 왜 필요한지, 이게 우리 소프트웨어가 적용되는 분야에서 중요한지를 몰랐습니다. 대부분 시스템에서 비번을 암호화 하지도 않았고요. 그때는 그냥 비번을 저장해두고 나중에 비교한다 정도가 도메인 지식이었을 겁니다.
근데 제가 PasswordEncoder를 도메인으로 생각한 건, 요즘엔 워낙 비밀번호 유출과 평문 저장으로 인한 각종 사고에 관한 기사가 일반 뉴스에도 많이 등장하고, 관심있는 비개발자분들도 다 이이야기를 하시더라고요. 그래서 이걸 경우에 따라 바뀔 수도 있는 기술적인 선택이 아니라, 서비스 운영 기관과 사용자, 혹은 관계자들 모두가 관심을 가지고 이야기를 나눌 수 있는 수준의 이제는 중요한 도메인 지식이 되었다고 느꼈기 때문입니다.
하지만 그걸 어떤 알고리즘을 사용한다 이런 얘기는 전문 보안회사에서 시스템을 만들고 고객도 개발자인 그런 특별한 케이스가 아니라면, 대부분은 도메인 지식에 포함되지 않을테니, 그건 도메인에서 분리하고 어댑터에 넣은 것이죠.
좋은 질문 주셔서 감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다. 기석님께서 남겨주신 흥미로운 질문에 대해 답변드리겠습니다.
도메인 로직이란 비즈니스 요구사항을 직접적으로 반영하는 핵심적인 코드 영역을 말합니다. 모든 코드가 도메인 로직일 수는 없는데요, 주로 비즈니스 규칙과 관련된 부분을 도메인 로직에 포함시킵니다. 도메인 로직은 시스템에서 “무엇”을 하는지를 정의하는데 중점을 두며, 도메인 모델을 통해 이를 구현하게 됩니다.
도메인 로직과 기타 코드의 차이점
도메인 로직: 비즈니스 요구사항과 직접적으로 연결된 부분입니다. 예를 들어, 비밀번호를 암호화해야 한다는 요구사항은 바로 도메인 로직에 해당됩니다.
기능적 로직: 이메일 전송, 파일 읽기/쓰기, UI 갱신 등과 같은 시스템의 기능을 수행하기 위한 로직입니다. 이는 비즈니스 규칙과 직접 관련이 없는 경우가 많습니다.
기술적 로직: 데이터베이스 접근, API 통신 등과 같은 기술적인 구현 사항입니다. 이는 비즈니스 규칙과 분리되어 있으며 주로 인프라스트럭처 계층에 위치합니다.
비밀번호 암호화 기능이 도메인 로직에 포함된다는 것은, 이 기능이 비즈니스적으로 중요한 규칙임을 의미합니다. 따라서 비즈니스 요구사항이 변화할 때 그에 맞춰 도메인 로직도 함께 변화하게 됩니다.
관련된 내용을 이해하는 데 도움이 되는 게시물을 참고하시기 바랍니다:
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.