빈약한 도메인 모델은 어떤게 해로운걸까?

DDD에서 풍부한 도메인 모델 (Rich Domain Models), 빈약한 도메인 모델 (Anemic Domain Models) 두 명칭을 갖고 여러가지 이야기를 다룬다.

 

이번 글에선 빈약한 도메인 모델이 개인적인 경험 기반으로 왜 해로운지 정리해보고자한다. (정말 해로운건 맞는지?, 있다면 그게 왜 해로운건지?, 트레이드 오프는 어떤게 있는지? 등을 파고자하는게 주 목적이다)

 

우선 두괄식으로 개인적으로 생각할 때, 빈약한 도메인 모델이 가장 크게 해롭다고 다가오는 이유는 캡슐화인것같다.

 

이를 형상화해보면, 빈약한 도메인 모델은 도메인 객체가 데이터를 담기만하고 논리(로직, 행위)는 서비스 클래스에 구현된다. 유저 금액을 예금하는 코드로보면 다음과 같다.

 

data class User(val name: String, val balance: Double)

class UserService {
    fun deposit(user: User, amount: Double): User {
        return user.copy(balance = user.balance + amount)
    }
}

유저는 그저 데이터만 담아두는 역할만 하고있, 예금 논리는 서비스로 빠져있다. 사실 이런 방식은 객체지향에서 나온 OOD (object oriented design) 접근 방식에서도 지양하려하는 모습이다.

 

위와 같은 형태로 코드가 작성되면 예상되는 문제는 아래와 같이 설명해볼 수 있을것같다.

 

1. 중복 가능성 증진

중요 도메인 논리가 서비스로 빠져있어 발견 가능성이 매우 낮아진다. 즉, 다양한 도메인 서비스와 프로세서를 구현할 때 해당 도메인 논리를 발견하지못하여 중복 코드 구현 가능성이 높아진다.

 

결국, 이러한 문제의 시작은 복잡한 현실세계(도메인)의 문제를 해결하기 위해 많은 요구사항이 존재할것인데, 이러한 논리를 코드로 구현하고자할 때 DDD에선 빌딩 블록들을 제공하여 도메인 모델을 설계한다. 이 때, 불변식에 대한 논리들이 서비스쪽으로 빠지게 되면 모델은 점점 더 얕아질 수 밖에 없다.

 

 

2. 캡슐화

객체 설계에서 캡슐화의 가장 중요한것은 `데이터 무결성을 보호하는 행위`라고 생각하는데, 이게 보장이 되지않는다.

 

도메인 모델을 캡슐화하면 정보 은닉을 통해 내부 정보가 최대한 외부에 노출되지 않도록하여 정보가 손상될 위험을 줄일 수 있고, 데이터와 작업을 번들링하면 도메인 객체 내부에서 수행하는 모든 작업에 대한 하나의 진입점을 만들 수 있다. (e.g. domain entity factory)

 

이와 같이 하나의 진입점에 도메인 객체가 생성될 떄 수행해야하는 불변식들을 공통적으로 수행하게 만들면 내부 상태를 수정하기 전에 필요한 모든 검증 및 무결성 검사를 수행할 수 있게된다.

 

개발을 하다보면, 비지니스가 확장되가면서 시스템은 복잡해질 수 밖에 없다고 생각한다. 이럴 때 필요한 영역의 캡슐화가 이루어지지않으면 중복 논리, 일관된 불변식이 아니게 되면서 스파게티 코드가 되기 쉬워진다. (물론 상황 by 상황이기에 트레이드 오프 생각하면서 오히려 필요한 부분에 계속 찍어내는게 나을 수 있는 상황도 있다고 생각한다)

 

이러한 기능 확장에 대한 복잡성을 시스템에서 핸들링하기 가장 적합한 방법중 하나가 캡슐화라고 생각하는데, 빈약한 도메인 모델은 이런 개념과 반대된다. 개인적으로 이게 가장 빈약한 모델의 문제점이라고 생각이 든다.

 

 

----

재밌는 그래프 발견

이 개념을 좀 더 파보고싶어 찾다가 재밌는 그래프를 발견했다. https://www.pluralsight.com/ 에서 발견했고, 빈약한 모델에서 풍부한 모델로의 리팩토링 과정을 나타내면서 사용한 이미지이다.

 

실제 엔터프라이즈에서 소요된 작업 시간을 기반으로 나타낸 그래프라고한다. 확실히 100% 이게 무조건 맞다라고 생각할 수 있는게 없듯 이것마저 명확한 트레이드오프가 따르는것같다.

 

앞서 말했던 상황 by 상황이 위 그래프로 설명해보자면, 정말 큰 고민없이 빠르게 초기에 실험을 한다던가, 해커톤을 한다던가 등등 미래보단 지금이 더 중요할 땐 데이터 그릇만 두고 서비스 논리 기반으로 풀어나가는게 더 직관적일 때가 있는것같다.