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

결합도가 높으면 어떤 변경이 다른 곳에 전파가 계속 됩니다.

그런데 PasswordEncoder는 인터페이스이고, 여기에는 비밀번호를 암호화한다라는 우리가 도메인을 분석했을 때 나온 로직만 표현되어 있습니다. 그걸 구현한 코드는 완전히 분리되어 있어서 암호화 기술을 변경하든 다른 방식으로 하든 그게 엔티티(Member)에 영향을 주지 않습니다. 그래서 결합도가 높지 않습니다.

비밀번호를 암호화한다라는 규칙을 바꾼다면, 그때는 변경이 필요한데 그건 어짜피 Member에 대한 로직이 변경되는 것이니 그때 PasswordEncoder가 빠지거나 달라지는 것은 아무 문제가 없습니다. 오히려 응집도가 높아지는 것이죠.

안녕하세요, 인프런 AI 인턴입니다. dmstjd0812님, 질문 주신 내용에 대해 답변을 드리겠습니다.

도메인 엔티티 내부에 passwordEncoder와 같은 객체를 넣는 것은 결합도를 높이는 것처럼 보일 수 있지만, 도메인 로직과 관련된 비즈니스적인 요구사항을 충실히 반영하는 데 중요한 역할을 합니다. 도메인 모델에서 비밀번호를 암호화하는 로직은 회원 가입 비즈니스 로직의 본질적인 일부로 간주될 수 있습니다.

도메인 로직 내의 passwordEncoder 사용

1. 비즈니스 규칙 구현: 비밀번호는 서비스의 중요한 비즈니스 규칙에 해당합니다. 회원의 비밀번호를 안전하게 관리하고 암호화하여 저장하는 것은 도메인 로직의 중요한 부분입니다. 따라서 도메인 모델에 passwordEncoder를 두는 것은 자연스러운 결정일 수 있습니다.

2. 응집도: 객체 지향 설계에서는 응집도가 높고 결합도가 낮은 설계를 추구합니다. 비밀번호를 어떻게 암호화할지는 도메인의 비즈니스 로직과 밀접하게 관련되어 있기 때문에, 도메인 내에 passwordEncoder를 두어 높은 응집도를 유지할 수 있습니다. 대신 암호화 방식이 변경되더라도 인터페이스를 통해 구현을 주입받아 사용하면 결합도를 낮출 수 있습니다.

결합도를 조정하는 방법

도메인 모델이 특정 기술에 의존하지 않도록 하기 위해 인터페이스를 활용하는 것이 좋습니다. PasswordEncoder를 인터페이스로 정의하고, 그 구현체를 어플리케이션 레벨에서 스프링의 DI(Dependency Injection)를 통해 주입받는 식으로 결합도를 낮출 수 있습니다.

관련된 내용이 잘 설명되어 있는 기존 질문과 답변을 추천드립니다:

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

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