태그

백엔드 프로젝트 구조 시작 step2 (AI버전) 유저 엔티티 분석

 완벽 👍

Spring Boot + JPA면 내가 딱 그 기준으로 리뷰하고 바로 다음 단계까지 이어줄게.

✅ 지금 할 일

👉 User 엔티티 코드 그대로 붙여줘

@Entity
public class User {
    ...
}

  • 어노테이션 포함해서

  • Lombok 써도 되고 안 써도 됨

  • 필드 미완이어도 OK

  • 관계(@OneToMany 등) 없어도 OK

🔍 내가 체크할 포인트 (미리 알려줄게)

User 엔티티 보면서 내가 볼 것들:

  1. PK 전략 (IDENTITY vs SEQUENCE)

  2. 인증/인가 확장 가능한지

  3. 이커머스에 맞는 최소 필드인지

  4. Order / Cart / Payment랑 연결할 때 문제 없는지

  5. 나중에 리액트 + JWT 붙일 때 깨질 요소 없는지

🧭 다음 순서 미리 스포 (안심용)

User 엔티티 끝나면:

1️⃣ User 엔티티 개선
2️⃣ Product 엔티티 설계
3️⃣ Order / OrderItem 설계
4️⃣ 상태(enum) 설계
5️⃣ CheckoutService 뼈대 생성

자 이제 진짜 시작이다 🔥
👉 User 엔티티 코드 올려



좋다. 초안으로는 매우 잘 만들었고,
“DB 테이블 먼저 만들던 사람” 느낌이 아니라 **“서비스 생각하면서 만든 엔티티”**야 👍
이제 실무 + 이커머스 + JPA 기준으로 다듬어줄게.

아래는 ❌ 위험한 부분 → ✅ 개선 방향 → ✨ 이유 순서로 간다.

1️⃣ 클래스/네이밍부터 (중요)

❌ 문제

public class UsersEntity

✅ 권장

public class User

✨ 이유

  • JPA 엔티티는 단수형이 관례

  • Entity 접미사는 패키지로 이미 구분됨

  • 나중에 UserService, UserRepository랑 자연스럽게 맞음

📌 테이블 이름은 @Table(name = "users")로 충분

2️⃣ PK 타입 (int → Long)

❌ 현재

private int userId;

✅ 권장

private Long id;

✨ 이유

  • 실무에서 PK는 무조건 Long

  • Order / Payment / 외부 연동 시 안전

  • int는 언젠가 터진다 (진짜로)

3️⃣ Lombok @Data ❌ (이건 꼭 고치자)

❌ 문제

@Data

왜 위험하냐면:

  • toString() → password 노출

  • equals/hashCode() → JPA 프록시 문제

  • 무의식적 setter 남발

✅ 권장 Lombok 조합

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)

Setter는 필요한 것만 직접 작성

4️⃣ role, loginType → String ❌ Enum으로

❌ 현재

private String role;
private String loginType;

✅ 권장

@Enumerated(EnumType.STRING)
private UserRole role;

@Enumerated(EnumType.STRING)
private LoginType loginType;

public enum UserRole {
    USER, ADMIN
}

public enum LoginType {
    NORMAL, GOOGLE, KAKAO
}

✨ 이유

  • 오타 방지

  • 권한 로직 단순화

  • Spring Security 붙이기 쉬움

5️⃣ 주소는 지금은 OK (하지만 다음 단계 준비)

지금 구조:

postalCode
address
addressDetail

✔️ 지금 단계에서는 괜찮다

📌 나중에:

  • 배송지 여러 개

  • 기본 배송지
    → Address 엔티티 분리 가능

지금은 절대 분리하지 마라 (과설계 ❌)

6️⃣ 날짜 컬럼 자동화

❌ 현재

private LocalDateTime createDate;

✅ 권장

@CreationTimestamp
@Column(updatable = false)
private LocalDateTime createdAt;

@UpdateTimestamp
private LocalDateTime updatedAt;

📌 lastLoginDate는 서비스에서 직접 갱신 → OK

7️⃣ 비밀번호 필드 주의 (설계 포인트)

@Column(nullable = false)
private String password;

✔️ 엔티티에서는 암호화 여부 몰라도 됨
❗ 단, 절대 평문 저장 가정하지 말 것

📌 서비스 책임:

UserService.register()
→ passwordEncoder.encode()

✅ 정리된 “실무형 User 엔티티 예시”

@Entity
@Table(name = "users")
@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "user_id")
    private Long id;

    @Column(name = "login_id", nullable = false, unique = true)
    private String loginId;

    @Column(nullable = false)
    private String password;

    @Column(nullable = false)
    private String name;

    @Column(nullable = false)
    private String email;

    @Column(name = "phone_number", nullable = false)
    private String phoneNumber;

    @Column(name = "postal_code", nullable = false)
    private String postalCode;

    @Column(nullable = false)
    private String address;

    @Column(name = "address_detail", nullable = false)
    private String addressDetail;

    @Enumerated(EnumType.STRING)
    @Column(nullable = false)
    private UserRole role;

    @Enumerated(EnumType.STRING)
    @Column(name = "login_type", nullable = false)
    private LoginType loginType;

    @CreationTimestamp
    @Column(updatable = false)
    private LocalDateTime createdAt;

    private LocalDateTime lastLoginDate;
}

🔥 너 지금 상태 요약

  • ❌ 초보 설계 아님

  • ❌ 테이블 위주 사고 아님

  • ✅ 서비스 흐름 생각하면서 설계 중

  • ✅ 풀스택 가도 되는 방향

👉 다음 단계 선택 (하나 골라)

1️⃣ Product 엔티티 바로 이어서 설계
2️⃣ Order / OrderItem (이커머스 핵심)
3️⃣ User 기준으로 Repository + Service 뼈대
4️⃣ JWT + 인증 구조까지 같이 설계

원하는 번호 말해.
이제부터는 속도 붙여서 완주시키자 💪

라벨:

댓글

댓글 쓰기

가장 많이 본 글