비즈니스 로직이 여기저기 파편화되고, 하나의 비즈니스 로직 안에 여러 책임과 로직이 뒤섞여 있는 상황이 반복됨.
각각의 모델에서 목적에 따라 제각각 비즈니스 로직을 정의하다 보니, 동일한 로직도 중복 작성되거나 수정 시 여러 곳을 일일이 찾아 수정해야 하는 문제가 발생.
또한, 복잡한 테이블 관계를 다루는 과정에서 잠재적인 버그, 상태 업데이트 누락, 코드 오류 등이 생길 위험도 커졌음.
이러한 문제점을 개선하고자, Eloquent에 Active Record 패턴을 도입하여 비즈니스 로직과 데이터 구조를 명확히 정리하고, 유지보수성과 안정성을 높이고자 한다.

Active Record 패턴이란?

Active Record 패턴은 데이터베이스 테이블 하나당 클래스 하나를 만들고, 그 클래스의 인스턴스가 테이블의 한 행(row) 을 나타내는 구조임. 객체와 데이터베이스 레코드를 1:1로 매핑하여, 해당 객체에서 CRUD (Create, Read, Update, Delete) 작업을 직접 수행함.

• 클래스 = 데이터베이스의 테이블
• 객체 = 데이터베이스의 행(Row)
• 객체의 속성 = 데이터베이스의 컬럼(Column)

1️⃣ 기존 Query Builder 스타일 (Active Record X)

// userService.php
public function updateUser($idx){
    User::where('id', $idx)
        ->update([
            'name' => '홍길동'
        ]);
}

2️⃣ Active Record 패턴 적용 (Eloquent ORM)

// User.php
class User extends Model {
    // users 테이블과 연결
}

// 데이터 수정
public function updateUser ($idx){
    $user = User::find($idx); // 객체 조회
    $user->name = 'John';  // 속성 변경
    $user->save();         // 변경 사항 저장
}

• 모델 인스턴스가 자신의 데이터 상태를 기억하고 있어, 변경 후 save()만 호출하면 자동 저장(or push())

✅ Active Record 패턴의 장점

• 코드 가독성 및 유지보수성 향상
  • 데이터와 관련된 로직을 한 곳(모델 내부)에 모아두어 코드 관리가 쉬움
  • 객체 내부 인스턴스와 컬럼이 1:1로 매핑, 어떤 상태를 변경하는지 명확함
  • 모델 레벨에서 재사용 가능
  • 유지보수 시 수정 범위 명확
    • 모델 하나에 해당 테이블 관련된 처리와 규칙이 모두 포함 → 수정 시 다른 파일이나 레이어까지 신경 안 써도 됨
• 중복 코드 최소화
  • 같은 데이터를 여러 번 조회하지 않고 인스턴스 상태를 유지하면서 업데이트 가능
  • 모델 안에서 비즈니스 로직을 처리하여 컨트롤러 코드가 간결해짐

비즈니스 로직이 모델에 있으면 서비스 레이어는?

Active Record 패턴을 사용할 때 서비스 레이어(Service Layer) 의 역할이 모호해지거나, 아예 생략되는 경우가 많음.

📌 Service Layer 생략으로 인한 문제점/한계

• 비즈니스 로직이 비대해질 수 있다

  • 모델 클래스에 데이터 처리, 비즈니스 로직, 관계, 커스텀 메서드 들이 계속 추가되면서, 모델이 점점 무거워지고 단일 책임 원칙(SRP) 을 위반할 가능성 커짐.

• 테스트가 어려워짐

  • 모델에 DB 처리 + 비즈니스 로직 이 뒤섞여 있어서, 유닛 테스트 작성 시 DB 의존성 피하기 어려움.

• 복잡한 도메인에서는 유지보수성이 떨어짐

  • 단순 CRUD + 간단한 비즈니스 로직일 땐 Active Record로 충분.
  • 하지만 도메인 규칙이 많아지고, 여러 엔터티 간 복잡한 연산이 필요할 때 모델에서만 처리하려고 하면 관계가 얽히고 꼬임.

무조건적으로 생략하면 안됨🤬

• 복잡한 비즈니스 로직
  • 모델 내부에서 감당하기 어려운 로직을 명확하게 분리
• 여러 모델/엔티티 간 복합 작업
  • 트랜잭션, 연관 관계 조정 등을 하나의 서비스로 관리
• 관심사 분리 원칙(SRP) 적용
  • 데이터 액세스(모델)와 비즈니스 처리(Service) 분리