(1분 읽기) 안드로이드에서 도메인 모델과 데이터베이스 Entity 🤔

개발하다 보면 "이건 Entity야? 도메인 모델이야?" 헷갈릴 때가 많아!
특히 MVVM + Clean Architecture를 적용할 때 데이터 계층과 비즈니스 로직을 어떻게 분리할지 고민되기도 하고.
오늘은 도메인 모델과 Entity의 차이점, 그리고 어떤 폴더 구조가 좋은지 쉽게 정리해볼게! 🚀

---

✅ 도메인 모델 vs 데이터베이스(Entity), 뭐가 다를까?

항목	도메인 모델 (Domain Model)	데이터베이스 엔터티 (Entity)
목적	비즈니스 로직을 표현하는 객체	데이터베이스 저장을 위한 객체
역할	애플리케이션의 핵심 데이터를 관리하고 가공	데이터베이스의 테이블과 1:1 매핑
구조	UI 및 비즈니스 로직에 맞춘 클래스	Room, Realm 등 DB 라이브러리와 함께 사용
예제	User(name: String, age: Int, email: String)	@Entity(tableName = "users") data class UserEntity(...)

📌 쉽게 말하면?
✔️ 도메인 모델 → 앱 내부에서 비즈니스 로직을 관리하는 객체
✔️ Entity → 실제 데이터베이스에 저장되는 객체

---

✅ 실제 코드 예제 (User 데이터 관리)

1️⃣ 데이터베이스 Entity (Room 사용)

@Entity(tableName = "users")
data class UserEntity(
    @PrimaryKey(autoGenerate = true) val id: Int = 0,
    val name: String,
    val age: Int,
    val email: String
)

✔️ @Entity 어노테이션을 사용해서 데이터베이스 테이블과 1:1 매핑
✔️ @PrimaryKey → 고유 ID를 자동 생성

---

2️⃣ 도메인 모델

data class User(
    val name: String,
    val age: Int,
    val email: String
)

✔️ @Entity 같은 데이터베이스 관련 코드 없음
✔️ 앱에서 비즈니스 로직을 다루는 순수 Kotlin 클래스

---

3️⃣ Entity ↔ 도메인 모델 변환

fun UserEntity.toDomainModel(): User {
    return User(
        name = this.name,
        age = this.age,
        email = this.email
    )
}

fun User.toEntity(): UserEntity {
    return UserEntity(
        name = this.name,
        age = this.age,
        email = this.email
    )
}

✔️ 데이터베이스에서 불러온 UserEntity를 도메인 모델(User)로 변환
✔️ 반대로, User를 데이터베이스에 저장할 때 UserEntity로 변환

📌 왜 이렇게 변환할까?

• 데이터베이스(Entity)와 UI(도메인 모델)를 완전히 분리해서 유지보수하기 쉽게 만들기 위해!
• 예를 들어 데이터베이스 구조가 바뀌어도 UI 코드가 영향을 받지 않도록 하기 위해! 🎯

---

✅ 안드로이드 프로젝트 폴더 구조 (MVVM + Clean Architecture 적용)

📌 도메인 모델과 Entity를 분리하면 폴더 구조도 깔끔하게 정리할 수 있어!
아래와 같은 폴더 구조를 추천해!

📂 com.onymo.app
 ├── 📂 data
 │   ├── 📂 local          # 로컬 DB 관련 (Room, SharedPreferences 등)
 │   │   ├── UserDao.kt
 │   │   ├── AppDatabase.kt
 │   ├── 📂 model
 │   │   ├── UserEntity.kt  # 데이터베이스 Entity
 │   ├── 📂 repository
 │   │   ├── UserRepository.kt  # 데이터 저장/불러오기 로직
 │
 ├── 📂 domain
 │   ├── 📂 model
 │   │   ├── User.kt   # 도메인 모델 (Entity와 분리)
 │   ├── 📂 usecase
 │   │   ├── GetUserUseCase.kt   # 비즈니스 로직 관리
 │   │   ├── SaveUserUseCase.kt
 │
 ├── 📂 ui
 │   ├── 📂 user
 │   │   ├── UserViewModel.kt  # UI에서 사용할 ViewModel
 │   │   ├── UserFragment.kt   # UI 화면

📌 이 폴더 구조의 핵심!
✔️ data → 데이터 저장 관련 코드 (Entity, DB, Repository 등)
✔️ domain → 비즈니스 로직 관련 코드 (도메인 모델, UseCase 등)
✔️ ui → 화면 관련 코드 (Fragment, ViewModel 등)

---

✅ 결론

📢 도메인 모델과 Entity를 분리하면?
✅ 데이터베이스 변경에도 UI와 비즈니스 로직이 영향을 받지 않음
✅ 코드가 깔끔해지고 유지보수가 쉬워짐
✅ MVVM + Clean Architecture 적용이 편리해짐

📢 추천 폴더 구조를 적용하면?
✅ 데이터 계층(data)과 비즈니스 로직(domain)을 분리하여 코드가 명확해짐
✅ 프로젝트가 커져도 체계적으로 관리할 수 있음

💡 이제 도메인 모델과 Entity를 분리해서, 유지보수하기 쉬운 코드를 만들어보자! 🚀