[DDD] 도메인 로직의 범위에 대해서

Question

안녕하세요.DDD를 혼자 공부해보고 있는 주니어 개발자입니다.제가 DDD를 공부하면서 DDD가 강조하는 핵심은 애플리케이션 서비스는 단순히 도메인 객체를 조합하는 역할이고, 핵심적인 비즈니스 로직은 도메인 계층에서 진행되어야 한다라는 것인 것 같습니다.하지만, 어디까지가 서비스 계층의 책임 범위이고 어디까지가 도메인 계층의 책임 범위인지가 아직 헷갈립니다.예를 들어, 로그인을 하는 로직이 있고, 로그인을 위해서 이메일과 패스워드를 사용자에게 받는다고 해보겠습니다. 이때 서비스는 userRepository.findByEmail을 통해 User 객체를 가져오고, 만약 User 객체가 없다면 예외를 처리한다고 하겠습니다. 이때 로그인하기 위해 검사하는 것이 비밀번호가 일치하는지와 탈퇴 회원인지 두 가지를 검사하고 둘 다 이상이 없으면 accessToken과 refreshToken을 리턴해준다고 하면, 아래의 두 상황에서 어떤 것이 DDD에 맞는 것인지가 궁금합니다.상황 1도메인 객체에 private으로 비밀번호 일치 확인, 탈퇴 회원 여부 확인 메소드를 만들고, public 메소드로 로그인하기 메소드를 만들어 이 로그인하기 메소드에서 이들을 검사하고 토큰을 만들어주는 방법.상황 2도메인 객체에 public으로 비밀번호 일치 확인, 탈퇴 회원 여부 확인 메소드를 만들어 서비스에서 이들을 호출하여 토큰을 만드는 방법.상황 1의 경우 비즈니스 로직에 따라 회원의 유효성을 검사하고 로그인을 하는 것까지가 모두 도메인 로직이기 때문에 도메인 계층에서 모두 실행하는 것이 맞다고 생각이 들고,상황 2의 경우 도메인 로직을 수행하는 도메인 객체들의 메소드들을 서비스에서 잘 조합해서 기능을 구현하는 것이기 때문에 서비스의 본래 역할이 도메인 기능을 잘 조합하는 파사드 역할을 잘 수행한 것 같아서 맞다고 생각이 듭니다.혹시 어떤 상황이 올바른 상황일까요?많은 검색과 고민을 해보았지만 애매하다고 생각이 되어 질문드립니다. 고수님들의 의견을 여쭤보고 싶습니다.

chytonpide · Accepted Answer

제가 DDD를 공부하면서 DDD가 강조하는 핵심은 애플리케이션 서비스는 단순히 도메인 객체를 조합하는 역할이고, 핵심적인 비즈니스 로직은 도메인 계층에서 진행되어야 한다라는 것인 것 같습니다.이 말도 맞지만, DDD 에서 중요한건 시스템 개발에 실제 도메인의 언어를 사용하는 점 인 것 같습니다.만들어 지는 모델, 오퍼레이션의 이름을 도메인에서 차용해서 유저나 개발자 같은 이해관계자들이 어느정도 통일된 관점을 가지도록 돕는 것 입니다.또 다른 DDD 방법론의 가치는 개발자가 따라할 수 있는 지침을 제공한다는 점 인것 같습니다.어플리케이션 레이어의 역할을 도메인객체를 준비하고 실행시키는 역할이다. 트랙잰션관리등 여러 '응용' 루틴은 어플리케이션 레이어에 위치시킨다.도메인 로직은 도메인에 둬라, 불변식을 지키는 집약 모델을 하나 만들고 그 모델을 통해서만 여러 모델의 상태를 수정할 수 있게 하라,동시성 문제가 아주 복잡하니, 하나의 트랜잭션에서 하나의 집약 모델만 수정할 수 있게 하라 등.단, 시스템을 여러 레이어로 나누고 핵심적인 계산들을 시스템의 가장 깊숙한 곳에 두는 것이 DDD에서만 주장하는 것은 아닙니다. 하지만, 어디까지가 서비스 계층의 책임 범위이고 어디까지가 도메인 계층의 책임 범위인지가 아직 헷갈립니다.'응용 서비스' 계층의 책임은 트랜잭션 관리 도메일 객체를 실행시키기 위한 준비 및 실행 입니다. 애초에 도메인계층이랑 응용 서비스 계층을 분리하는 이유가 뭘까요? 도메인계층에서 처리하는 로직이 이미 충분히 복잡하고 어렵기때문에, 트랙잭션 관리, 도메인 모델 준비등(레포이토리에서 도메인 모델 불러오기, 다른 서비스와 통신해서 필요한 데이터 모으기) 같은 걸 분리하는 겁니다. 이렇게 도메인 로직만 테스트할 수 있습니다.저는 도메인 로직이 조금 어플리케이션으로 새어나와도 괜찮다는 입장입니다. 예를들어 'User 는 중복된 이름을 가질 수 없다'는 도메인 규칙이 존재 할때 유저 이름을 수정하는 오퍼레이션을, User의 오퍼레이션으로 구현할 수 있을까요? 보통 어플리케이션 서비스에서 이름으로 User를 검색한 다음 중복된 이름이 있다면 에러를 돌려주는 식으로 구현할 겁니다.분명 'User 는 중복된 이름을 가질 수 없다' 는 도메인 로직인데 어플리케이션이 의사결정을 합니다.public void changeUserName(changeUserNameCommand) { User userOfName &#61; userRepository.findUserByName(command.userName()); if(userOfName !&#61; null) { throw new ValidationErrorException(&#34;중복된 유저이름이 존재합니다&#34;) } ... }예를 들어, 로그인을 하는 로직이 있고, 로그인을 위해서 이메일과 패스워드를 사용자에게 받는다고 해보겠습니다. 이때 서비스는 userRepository.findByEmail을 통해 User 객체를 가져오고, 만약 User 객체가 없다면 예외를 처리한다고 하겠습니다. 이때 로그인하기 위해 검사하는 것이 비밀번호가 일치하는지와 탈퇴 회원인지 두 가지를 검사하고 둘 다 이상이 없으면 accessToken과 refreshToken을 리턴해준다고 하면, 아래의 두 상황에서 어떤 것이 DDD에 맞는 것인지가 궁금합니다.DDD에 관점에서 보면, 토큰기반 인증을 사용한다는건 기술적인 메카니즘이고, 신원 확인 도메인과는 분리해야 할 것 같습니다.정말 잘, 엄격하게 DDD를 적용해서 설계한다면 도메인 계층에는 아무런 변화를 주지않고 토큰기반 인증을 스프링 세큐리티를 사용한 인증으로 바꿀 수도 있고, 혹은 또 다른 인증 메카니즘으로 바꿀 수도 있겠죠.저라면 토큰 관련은 별도의 모델로 구현해서 user 와 연관 시키고, User 는 token 에 관해서는 무지하도록 만들고 응용 서비스레이어에 말하신 로직을 위치시킬 것 같습니다. 참고https://github.com/VaughnVernon/IDDD_Samples/tree/master/iddd_identityaccess/src

개발잡부 · Answer

(저번글까지 포함하여 답변드리자면) 보통 인증/인가는 global로 따로 관리합니다. 도메인으로 넣지 않구요.

wharup · Answer

획일적으로 이야기하기 어렵겠지만 어플리케이션 로직은 해당 어플리케이션(시스템)의 로직이고 도메인 로직은 순수 비즈니스(업무) 로직이라고 보시면 됩니다.그런데 로그인하고 사용자 관리하는 기능은 그 자체가 어플리케이션 로직으로 봐야하니 그 안에서 도메인 로직을 이야기하기 좀 애매합니다.어떻게건 업무 로직 같은 걸 추가해서 회원 관리라는 업무가 있다고 볼 때 다음 같은게 도메인 로직이 됩니다. &#34;일반 회원은 가입했을 때는 신입 회원 등급이 되고, 30회 이상 시스템에 접속하면 일반 회원 등급이 된다.&#34;

[DDD] 도메인 로직의 범위에 대해서

3개의 답변

Q&A 목록