Domain Layer를 더 잘 표현하기 위한 Kotlin 문법
왜 Domain Layer는 순수해야 하는가?
회사에서 코드 리뷰를 받다가 domain layer 는 특히 더 중요하게 리뷰하고 있다는 조언을 듣게 되었다. Domain Layer의 Domain Model을 만들었다고 생각했는데, 실질적으로 살펴봤을때 데이터베이스의 테이블을 Kotlin Class로 옮겨놓은 것 뿐이었다. 도메인의 행위와 규칙은 없고, 데이터 구조만 남아있었다.
예를 들어서, 주문 테이블이 있었다고 치면 테이블의 컬럼들은 아래와 같을 것이다.
orders
- id
- user_id
- status
- total_price
- created_at
- updated_at이걸 그대로 옮기면 Order 라는 도메인 모델처럼 보이지만, 실제로는 orders 테이블을 표현한 데이터 구조가 되어버린다.
data class Order(
val id: Long,
val userId: Long,
val status: String,
val totalPrice: BigDecimal,
val createdAt: LocalDateTime,
val updatedAt: LocalDateTime
)DDD 에서 Domain 은 단순히 데이터를 담는 객체가 아니라, 비즈니스의 핵심 개념과 비즈니스의 제약 및 규칙을 담아야 하는 영역이다. Domain Layer는 DB, Framework, API, UI, 외부 시스템 같은 세부사항에 의존하지 않아야 한다. Domain Layer 는 어플리케이션에서 가장 오래 살아남아야 하는 핵심 영역이기 때문이다. DB, Framework 등은 바뀔 수 있지만 비즈니스 규칙은 상대적으로 오래 유지된다. 비즈니스 규칙과 기술 세부사항들이 섞여있으면, 기술적인 변경이 일어날 때마다 비즈니스 로직도 같이 흔들리게 된다. 따라서 Domain Layer 는 세부 사항에 대해서 몰라야 하며, 관심사를 분리해야 한다.
그렇다면 Kotlin은 이런 Domain Model을 더 잘 표현하기 위해 어떤 기능을 제공할까?
| DDD 에서 표현하고 싶은 것 | Kotlin 문법 |
| 변경을 최소화하는 객체 | val |
| 값 자체가 중요한 객체(Value Object) | data class |
| 식별자를 명확한 타입으로 표현 | value class |
| 생성 규칙 강제 | private constructor |
| 생성 책임 분리 | companion object |
| 상태를 안전하게 표현 | sealed class |
1. val
val 은 참조를 변경할 수 없다. 예를 들어서, 주문 금액인 totalPrice 가 중간에 order.totalPrice = BigDecimal.ZERO 로 변경되어 버리면, 문제가 될것이다.
class Order(
val id: OrderId,
val totalPrice: Money
)2. data class
DDD에서는 Value Object 라는 개념이 있다. 식별자가 아니라, 값 자체로 의미를 가지는 객체이다. 두 객체의 속성이 같다면 같은 객체로 취급 할 수 있다. 예를 들어서, 금액과 통화를 나타내는 Money 있다고 하자.
enum class Currency {
KRW,
USD,
JPY
}
data class Money (
val amount: BigDecimal,
val currency: Currency
)Money(1000, KRW) 와 Money(1000, KRW) 는 같은 객체로 취급할 수 있다.
3. value class
도메인 모델에서 식별자를 단순하게 Long, String 타입으로 두면 비즈니스 적으로는 다른 개념인데도 불구하고 코드상으로는 구분되지 않아서 컴파일러 입장에서는 넘거가게 된다.
val orderId: Long = 1L
val userId: Long = 1L
cancelOrder(userId) // 실수로 userId를 넘겨도 컴파일 에러가 안 남Kotlin에서는 @JvmInline value class를 사용해서 식별자를 별도 타입으로 감쌀 수 있다.
@JvmInline
value class OrderId(val value: Long)
@JvmInline
value class UserId(val value: Long)
@JvmInline
value class ProductId(val value: Long)Order 에서 단순하게 Long, String 타입 대신 value class 를 통해서 식별자를 표현할 수 있다. 이렇게 되면 컴파일 타임에 잘못된 식별자를 잡을 수 있게 된다.
data class Order(
val id: OrderId, // 비즈니스 개념을 포함하게 된 식별자
val userId: UserId,
val productId: ProductId
)
4. private constructor
객체 생성 시점부터 비즈니스 규칙을 지키게 만드는 게 중요하다. private constrictor 는 도메인 객체가 항상 유효한 상태로만 존재하도록 강제하는 장치이다.
예를 들어서 주문은 최소 하나 이상의 item 을 가져야 한다는 비즈니스 규칙이 있을 수 있다.
class Order(
val id: OrderId,
val items: List<OrderItem>,
val status: OrderStatus
)그렇지만 위와 같이 만들어버리면, items 에 emptyList 를 담아버리면 주문한 아이템이 없는데도 주문이 생성되게 되어버릴 것이다.
val order = Order(
id = OrderId(1L),
items = emptyList(),
status = OrderStatus.CREATED
)private constrictor 를 통해 외부에서 직접 객체를 생성하는 것을 막고, 반드시 create() 함수를 통해서만 객체를 생성하도록 강제할 수 있다.
class Order private constructor(
val id: OrderId,
val items: List<OrderItem>,
val status: OrderStatus
) {
companion object {
fun create(
id: OrderId,
items: List<OrderItem>
): Order {
require(items.isNotEmpty()) {
"주문 항목이 없는 주문은 생성할 수 없습니다."
}
return Order(
id = id,
items = items,
status = OrderStatus.CREATED
)
}
}
}
// create 함수를 통한 Order 객체 생성 예시
val order = Order.create(
id = OrderId(1L),
items = listOf(orderItem)
)5. companion object
companion object는 클래스 안에 붙어 있는 공용 객체 이다.
class Nickname private constructor(
val value: String
) {
companion object {
fun create(input: String): Nickname {
val trimmed = input.trim()
require(trimmed.isNotBlank()) {
"닉네임은 비어 있을 수 없습니다."
}
return Nickname(trimmed)
}
}
}외부에서 객체를 만들지 않고도 Member.create() 를 호출할 수 있다.
위의 예시처럼 companion object 안에 객체를 생성하는 메서드를 둘 수 있다.
이 메서드는 정적 팩토리 메서드처럼 사용할 수도 있다. 외부에서 도메인 객체의 필드 값을 마음대로 넣도록 생성자를 열어두는 대신, 팩토리 메서드 내부에서 필요한 값을 조립하고 검증한 뒤 도메인 객체를 생성하게 만들 수 있다. 이렇게 하면 생성 규칙을 한 곳에 모을 수 있고, 외부 계층의 관심사와 도메인 생성 규칙을 분리할 수 있다.
class Order private constructor(
val id: OrderId,
val userId: UserId,
val items: List<OrderItem>,
val status: OrderStatus,
val totalPrice: Money
) {
companion object {
fun createFrom(
cart: Cart,
orderId: OrderId
): Order {
require(!cart.isEmpty()) {
"장바구니가 비어 있으면 주문을 생성할 수 없습니다."
}
// 함수 내에서 값을 조합하여 도메인 객체를 생성한다.
val orderItems = cart.items.map { OrderItem.from(it) }
val totalPrice = orderItems.fold(Money.ZERO) { acc, item ->
acc + item.totalPrice()
}
return Order(
id = orderId,
userId = cart.userId,
items = orderItems,
status = OrderStatus.Created,
totalPrice = totalPrice
)
}
}
}
6. sealed class
도메인 객체는 보통 상태를 가진다. 주문 상태는 아래와 같은 상태들을 가질 수 있을 것이다. 상태를String으로 표현하면 오타나 잘못된 값이 들어와도 컴파일 시점에 막을 수 없다.
enum class OrderStatus {
CREATED,
PAID,
SHIPPING,
CANCELLED
}enum class 을 사용하면 가능한 상태 목록을 제한하여 안전하게 상태를 다룰 수 있다. 위의 경우에는 충분해보이지만, 상태마다 필요한 데이터가 다른 경우에 모든 정보를 담기 부족하다.
sealed class를 사용하면 가능한 상태를 제한하면서, 각 상태가 가져야 하는 데이터를 타입으로 함께 표현할 수 있다. 예를 들어 결제 완료 상태는 결제 시각을 가지고, 배송 중 상태는 운송장 번호를 가지며, 취소 상태는 취소 사유를 가질 수 있다.
sealed class OrderStatus {
data object Created : OrderStatus()
data class Paid(
val paidAt: LocalDateTime
) : OrderStatus()
data class Shipping(
val trackingNumber: String
) : OrderStatus()
data class Cancelled(
val reason: String,
val cancelledAt: LocalDateTime
) : OrderStatus()
}sealed class 로 상태 관리를 할때, when 절과 함께 쓰게 되면 일부 로직에서 처리를 빼먹는 실수를 방지할 수 있다.
fun canCancel(status: OrderStatus): Boolean {
return when (status) {
is OrderStatus.Created -> true
is OrderStatus.Paid -> true
is OrderStatus.Shipping -> false
// Cancelled 처리가 빠짐. 컴파일 에러 발생!
}
}도메인 모델에서는 아래와 같이 활용할 수 있다.
class Order private constructor(
val id: OrderId,
private var status: OrderStatus
) {
fun pay(paidAt: LocalDateTime) {
if (status !is OrderStatus.Created) {
throw IllegalStateException("생성된 주문만 결제할 수 있습니다.")
}
status = OrderStatus.Paid(paidAt)
}
fun startShipping(trackingNumber: String) {
if (status !is OrderStatus.Paid) {
throw IllegalStateException("결제 완료된 주문만 배송을 시작할 수 있습니다.")
}
require(trackingNumber.isNotBlank()) {
"운송장 번호는 비어 있을 수 없습니다."
}
status = OrderStatus.Shipping(trackingNumber)
}
fun cancel(reason: String, cancelledAt: LocalDateTime) {
if (!canCancel()) {
throw IllegalStateException("현재 상태에서는 주문을 취소할 수 없습니다.")
}
status = OrderStatus.Cancelled(
reason = reason,
cancelledAt = cancelledAt
)
}
private fun canCancel(): Boolean {
return when (status) {
is OrderStatus.Created -> true
is OrderStatus.Paid -> true
is OrderStatus.Shipping -> false
is OrderStatus.Cancelled -> false
}
}
}
Entity 를 Data Class 로 만들지 않는 이유
entity 라는 개념은, 식별자를 가지고 있다. 식별자가 같으면 필드값이 좀 바뀌어도 같은 객체로 취급한다.
class Member(
val id: MemberId,
var nickname: Nickname,
var status: MemberStatus
)예를 들어서, 인스타그램의 닉네임을 바꾼다고 해서 그 회원이 달라지지는 않을 것이다. Member(1L, 'freemjstudio', 'active') 와 Member(1L, 'thisisminjiwoo')는 동일한 객체로 취급한다.
반면에 data class 의 기본 equals() 는 모든 프로퍼티를 기준으로 비교한다.
val member1 = Member(
id = MemberId(1L),
nickname = Nickname("민지"),
status = MemberStatus.Active
)
val member2 = Member(
id = MemberId(1L),
nickname = Nickname("minjee"),
status = MemberStatus.Active
)
println(member1 == member2) // falseid 는 같은데 닉네임이 다르기 때문에 false 로 리턴된다. 따라서 일반적으로 생각하는 도메인의 개념과 data class 의 equals 개념은 다르기 때문에 data class 로 entity 를 구현하면 어색하다.
data class 의 copy() 함수도 도메인 Entity 의 개념을 위반할 수 있다.
data class Order(
val id: OrderId,
val status: OrderStatus,
val totalPrice: Money
)
val paidOrder = order.copy(
status = OrderStatus.Paid
)기존 order 를 복사해서, status 만 결제 완료 상태로 바꾼 새로운 Order 객체를 생성하고 있다. 결제 상태로 변경이 되기 위한 다른 비즈니스 규칙들은 모두 건너뛰고 copy 함수로 상태 변경이 일어나기 때문에, 검증할 수가 없게 된다.