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

안녕하세요.

이메일의 검증 로직은 이메일이라는 형식은 고정되어 있고 이를 검증하는 로직이 시간이 지남에 따라 발전할 가능성은 없을 것이라고 봤기 때문에 검증 로직은 그대로 고정했습니다. 다만, 이메일 VO의 경우 회원 뿐 아니라 다른 엔티티에서도 사용될 가능성이 높기 때문에 이메일을 공통 VO로 분리했던 것이죠.

반면에 비밀번호 암호화는 기술적으로 여러가지 변경 가능성이 높습니다. 물론 서비스가 정식으로 운영되기 시작한 시점 이후에는 바뀌지 않을 수도 있지만, 여러가지 이후로 변경이 필요할 가능성이 있고(같은 종류의 비밀번호 로직이라도 성능을 위해서 암호화 전용 서비스를 API로 호출하거나 별도의 라이브러리를 이용하도록 외부화 할 수도 있겠죠), 서비스 개시 전까지는 보안 점검을 하면서 다양한 구현 알고리즘과 로직 구성 방식을 적용할 수 있어야 합니다. 그래서 외부에서 주입하기에 적당하기 때문에 이를 주입 받아 사용하도록 일종의 전략 패턴 사용했습니다.

비슷하지만 분명한 차이가 있는 두 가지 대상이라고 저는 판단했는데요. 혹시 다른 의견이나 제안이 있으시면 알려주세요.

안녕하세요, 인프런 AI 인턴입니다. kamser님, 질문 주신 내용과 관련하여 답변을 드리도록 하겠습니다.

도메인 모델에서 값 객체(Value Object, VO)를 사용하는 이유는 주로 데이터를 불변하며 안전하게 관리하고, 관련된 비즈니스 로직을 해당 객체 내에 국한시켜 응집도를 높이는 데 있습니다. 이메일과 패스워드는 모두 이러한 특성을 지니고 있어 VO로써 사용하기에 적합합니다.

질문 주신 바와 같이 패스워드를 문자열로 처리하는 대신 패스워드 VO를 만들어 관리할 수 있지만, 여기에서 패스워드 암호화 로직이 관여하기 때문에 몇 가지 고려사항이 존재합니다.

1. 암호화 로직의 책임 분리: 패스워드를 암호화하고 매치 여부를 확인하는 로직이 PasswordEncoder와 같은 별도의 인터페이스나 서비스에 의존하게 되면, 패스워드 VO는 그저 암호화된 데이터를 관리하는 데 집중할 수 있습니다. 이는 SOLID 원칙 중 단일 책임 원칙(Single Responsibility Principle)을 지킬 수 있는 방법입니다.

2. 의존성 주입의 유연성: PasswordEncoder는 비즈니스 로직과 인증 로직에서 다양하게 사용할 수 있는 컴포넌트입니다. 상황에 따라 다른 암호화 방법을 사용하거나 구현을 변경할 필요가 있을 때, VO에 의존성이 직접적으로 주입되지 않는 구조가 더 유연하게 대응할 수 있습니다.

패스워드를 VO로 관리하더라도, 암호화 과정에서는 PasswordEncoder를 의존성 주입받아 사용하는 구현이 필요한 경우가 많습니다. 다만, 패스워드의 평문 데이터를 앱 내부에서 직접 다루지 않도록 주의하며 암호화된 상태로 유지 및 비교하는 책임을 분리하는 것이 중요합니다.

관련된 내용이 잘 설명되어 있는 기존 질문과 답변을 추천합니다. 해당 답변은 Value Object와 도메인 서비스의 관계를 잘 설명하고 있습니다:

• 인터페이스 위치를 결정하는 기준에 대해
  

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