인프런 커뮤니티 질문&답변
작성한 질문수
Member 도메인이 PasswordEncoder를 받는 구조 질문 있습니다.
작성
·
10
0
예제에서는 도메인에 별도 PasswordEncoder 인터페이스를 정의해 사용하고 있습니다.
만약에, Member 도메인이 Spring Security의 PasswordEncoder 인터페이스를 직접 의존한다면, 구현체가 아니라 인터페이스를 참조하더라도 순수 도메인 설계 관점에서 위반으로 봐야 할까요?
저는 인터페이스 의존이라 괜찮을 수 있다고 생각했지만 AI는
도메인에서는 자체 PasswordEncoder 포트만 사용하고,
Spring Security PasswordEncoder는 인프라 어댑터에서 위임하는 것이 좋다.
고 제안했습니다.
토비님은 어느 쪽이 더 적절하다고 보시는지, 판단 기준도 함께 듣고 싶습니다.
답변 1
0
안녕하세요, 인프런 AI 인턴입니다. 이런개발님께서 제기하신 질문에 대해 답변드리겠습니다.
도메인 모델이 외부 라이브러리, 특히 특정 기술에 종속적인 인터페이스나 클래스를 직접 의존하는 것은 일반적으로 권장되지 않습니다. 이는 도메인 모델의 순수성을 유지하고, 기술적인 변화에 대해 유연하게 대응할 수 있는 구조를 만들기 위한 것입니다.
도메인의 순수성을 위한 설계 기준
기술적 종속성 회피: 도메인이 특정 프레임워크나 라이브러리의 API에 종속되면, 나중에 라이브러리를 교체하거나 업그레이드할 때 영향을 받게 됩니다. 이러한 종속성을 피하기 위해 도메인에서는 자신만의 인터페이스(포트)를 정의하고, 외부 기술에 대한 의존성은 인프라스트럭처 계층에서 해결하는 것이 바람직합니다.
변화에 대한 유연성: 애플리케이션 아키텍처가 변화하거나, 새로운 요구사항이 추가될 때, 도메인 모델을 최대한 변경하지 않고도 대응할 수 있어야 합니다. 자체적으로 PasswordEncoder 인터페이스를 정의하면, 이를 구현하는 다양한 전략을 쉽게 전환할 수 있습니다.
헥사고날 아키텍처 원칙 준수: 헥사고날 아키텍처에서는 외부 세계와의 경계를 명확히 하고, 도메인 모델이 비즈니스 로직에 집중할 수 있도록 설계합니다. 따라서, 외부 기술과의 의존성을 도메인 영역에서 분리하는 것이 중요합니다.
이러한 이유로, 도메인에서는 자체적으로 필요한 인터페이스를 정의하고, Spring Security의 PasswordEncoder와 같은 외부 구성 요소는 어댑터 계층에서 도메인의 인터페이스를 구현하는 형태로 위임하는 것이 적절한 접근 방식으로 여겨집니다.
관련된 질문과 답변을 통해 더 깊이 있는 이해를 도와드릴 수 있습니다:
- 인터페이스 위치를 결정하는 기준에 대해
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.