JPA Entity에 비즈니스 로직을 넣는 이유

Question

자바지기님의 JPA 질답 게시판을 따라하면서 열심히 배우고 있던 도중 이해가 안가는 부분이 있어 질문드립니다.

예로 유저의 비번을 체크하는 로직이 있습니다

if (!password.equals(user.getPassword()) {
    // blah blah
}

자바지기님의 추천은 Entity의 필드(패스워드)를 꺼내서 쓰는 행위보단 비번 validate 로직을 User 클래스에 넣어서 아래와 쓰는식이 좋다라고 하셨습니다

User 클래스:

public class User {
    private String password;
    public boolean matchPassword(String password) {
        if (password != null && password.equals(this.password) {
            return true;
        }
        return false;
    }
}

로직:

if (!user.matchPassword(password)) {
    // blah blah
}

제가 지금까지 알았던 Entity의 개념은 단순히 POJO로써 데이터를 홀드하는 역할만 하고, 비즈니스 로직은 util이건 서비스건 다른쪽에서 담당하는것이 맞다고 생각하는데 자바지기님께서 저렇게 쓰는 방식을 추천하는데에는 이유가 있을거라 생각합니다.

제 생각은 비즈니스 로직을 Entity에 넣을 경우 coupling이 생겨 (이 경우엔 없지만) 테스트도 힘들어지고 의존성이 생기기 때문에 좀 반대되는 입장인데 지식좀 공유해주시면 감사하겠습니다!

LichKing · Answer

음...자바지기님이라는건 아마도 슬립에 올린글을 여기다가도 올리신건가요?ㅎㅎ

일단 POJO가 뭔지부터 고민을 해보셔야할것같네요. POJO는 데이터를 들고만있는 클래스가 아닙니다. 글쓴분이 말씀하시는건 POJO보다는 DTO성향이 강한데요. 로직을 엔티티에 넣을경우 어떤 결합이 생기고 어떤 측면에서 테스트가 힘들어지는지를 말씀해주시는게 좀 더 좋을것같아요.

fender · Answer

결합도(coupling)과 응집도(cohesiveness)는 구분해서 생각해볼 수 있습니다. 예로드신 유효값 검증에 대한 비즈니스 로직이 UI적 특성 - 예컨대 주민번호를 두 개의 입력으로 나누어 받는다던지 - 하는 내용에 의존한다면 말씀대로 이를 엔티티에 구현하는 것은 계층간의 불필요한 결합도를 증가시킬 것입니다.

하지만 유효값 검증이 사용자라는 엔티티라는 개념 자체에 강하게 종속된 개념 - 예들들어 사용자의 아이디에 대한 규칙 - 이라면 그런 개념을 엔티티에서 분리하는 것이 오히려 응집성을 해치는 결과를 가져올 수 있습니다.

응집도가 떨어진다는 것은, 예컨대 연관된 코드를 한 곳에서 파악하기 어렵고 UI 구현을 바꾸었는데 핵심 비즈니스 코드까지 재구현을 해야한다던지 하는 식의 문제를 야기할 수 있습니다.

참고로 보다 적극적으로 엔티티의 속성과 동작을 결합하는 접근에 대해서는 도메인 주도 개발 방법론(DDD - Domain Driven Development)를 참조해보시면 좋습니다.

narise · Answer

입력값 검증은 비니즈니 로직으로 볼 수없습니다.

DB참조 중복체크가 필요 없고,

의존/분할 항목필드(생년 월 일)이 없거나 자세한 메세지를 보여줄 필요가 없을 때는 좋을 것같습니다.

fender · Answer

narise// 그 부분은 해석이 갈릴 수 있는 부분일 듯 합니다. '입력값'이라는 측면에 초점을 두면 UI에 종속적인 개념으로 비즈니스 로직이 아니라고 할 수 있지만, 도메인 객체의 속성에 대한 유효성 규칙이라는 측면을 보면 반대의 결론을 얻을 수 있습니다.

제 기억에 이는 유효성 검사 규칙을 계층별로 중복하는 문제와 연관해서 이전부터 가끔 논란이 되던 주제였던 듯 합니다.

이미 UI 기술이 다양한 입력값 검사 기능을 제공함에도 불구하고 자바의 Bean Validation 스펙과 같이 모델 차원에서 해당 기능을 통합하려는 시도 역시 유효성 규칙을 비즈니스 규칙의 일부로 보는 시각과 맥락을 같이한다고 이해할 수도 있습니다.

javaing · Answer

LichKing님

제가 알기로는 보통 JPA 엔티티를 POJO라고 칭하는것으로 알고있습니다. 제 짧은 지식으로써는 DTO 또한 POJO로 칭할수 있을것 같은데..

POJO stands for “Plain Old Java Object” — it’s a pure data structure that has fields with getters and possibly setters, and may override some methods from Object (e.g. equals) or some other interface like Serializable, but does not have behavior of its own. It’s the Java equivalent of a C struct

자바지기=박재성님의 동영상을 정주행하는 중입니다 ㅎㅎ

javaing · Answer

fender님 narise님

질문하기전 구글링을 해봤는데 DDD에 대한 대용을 살짝 보았는데 금방 이해를 할수 있을지는 잘 모르겠지만 자세히 한번 공부해봐야겠네요. 아직까진 엔티티에 getter/setter외에 다른 로직을 넣는거에 대해 fully convince 되지는 않았지만 그래도 여러 의견들을 듣고 생각해볼수 있어 좋습니다! 의견/조언 전부 감사드립니다

JPA Entity에 비즈니스 로직을 넣는 이유

6개의 답변

Q&A 목록