[Spring] Entity Class와 OOP

들어가면서

JAVA는 객체 지향 프로그래밍 패러다임을 사용하고 있는 언어입니다. 객체 지향 프로그래밍, 즉 OOP는 객체는 모두 자율적인 객체여야 하며, 이때 자율적인 객체라는 의미는 객체가 자신의 상태를 직접 관리하고 스스로의 결정에 따라 행동하는 객체임을 의미합니다.

그런데, Spring을 이용하여 개발할 때, Entity 클래스는 Database의 Table과 1:1 매칭되는 객체를 의미합니다. 그리고 상태(필드)만 가질 뿐, 해당 엔티티에 대한 책임(매서드)는 온전히 가지고 있지 못한 상태로 보입니다. 그래서 어떻게 해야 OOP 관점에서 Entity 클래스를 정의하는게 좋을 지 정리하고자 합니다.

OOP 단어 정의

OOP에서 자주 등장하는 단어 협력, 책임, 역할을 간단하게 설명하면 다음과 같습니다.

• 협력: 객체간의 상호작용
• 책임: 객체의 행동 (편하게 객체의 매서드)
• 역할: 책임(매서드)들이 모여 객체가 담당하는 범위

Entity 클래스의 역할

ORM을 사용할 때, Entity 클래스는 데이터베이스의 테이블의 저장될 데이터와 객체간의 매핑을 담당합니다. 이런 관점에서 Entity 클래스는 온전히 OOP적인 모델링을 하기 쉽지 않습니다. 하지만 이런 설계 방식이 실제 업무 상황에서 유용한 경우가 많습니다. 대부분의 웹 애플리케이션은 CRUD 기능이 중심이 되기 때문에, 데이터의 구조와 연산을 분리한 모델링이 효율적일 수 있습니다.

Entity의 책임은 Entity 객체, Service 계층 객체, Repository 계층 객체에 나뉘어 있습니다. 이때 Entity의 책임의 위치를 어떤 기준으로 나눌 수 있을까요?

Entity 책임의 위치

1. Entity 객체의 상태 변경 → Entity 계층에서 정의

예를 들어, UserAccount.updateStatus(ADMIN)과 같이 엔티티 객체의 상태 변경은 Entity 객체에서 책임을 가집니다. 하지만, 다른 객체들과 협력해야 하는 복잡한 책임은 Entity 계층에선 책임지기 어렵습니다.

2. 데이터 액세스 로직 → Repository 계층에서 정의

일반적으로 아는 사실이니 넘어가도록 하겠습니다

3. 비즈니스 로직 → Service 계층에서 정의

다양한 객체와 협력해야 하는 경우, 일반적으로 Service 계층에서 책임을 가지고 있습니다.