이번 자동차경주 리팩터링 미션에서 데이터베이스 요구사항을 추가하게 되었습니다.

이 과정에서 원래 있던 도메인 모델과 다른 데이터베이스 테이블과 매핑할 db 모델을 새로 만들어 주었는데요, 의도적이진 않았지만 이 분리를 통해 코드의 유연성을 더해줄 수 있었습니다. 또다른 장점이나 단점은 없을지 더 학습을 해봤습니다.

장점

관심사의 분리

‘어느 기능에 집중하느냐.’ 관심사의 분리는 책임의 분리와도 같습니다. DB 모델을 도입하면, 더이상 도메인 모델은 데이터베이스의 구조를 신경쓰지 않아도 됩니다. 도메인 모델은 비즈니스 로직에 집중할 수 있게 된다. 이는 데이터베이스 계층과 도메인 모델의 결합도를 매우 낮출 수 있게 돼요.

클라이언트가 사용하지 않는 기능을 갖는 인터페이스가 생겼다면 인터페이스가 구현에 의존적이지는 않은지 생각해봐야한다는 것을 다 아실 것입니다.

여기서, 도메인 로직과 데이터베이스 계층은 다음과 같이 볼 수 있습니다.

• 도메인 로직 = 인터페이스
• 데이터베이스에 접근하는 로직 = 각 구현체의 특성

데이터를 방법 중 하나인 데이터베이스에 도메인 로직이 의존하게 되면 안되겠죠. 이럴 때 관심사 분리, 즉 db 모델을 통해 코드를 클린하게 유지할 수 있게 됩니다.

유연성

도메인 모델과 db 모델을 분리하면 도메인 모델이 데이터베이스 스키마와 독립적으로 개발될 수 있습니다. 이말인 즉슨, 도메인 모델을 통해 비즈니스 로직을 구현할 때 데이터베이스 구조는 전혀 고려하지 않아도 된다는 것입니다.

단점

복잡함

데이터베이스 모델을 분리하는 것은 시스템에 하나의 계층을 추가하는 것과 같습니다. 데이터베이스 모델과 도메인 모델을 매핑하는 코드도 따로 마련해야합니다. 개발 시간도 증가될 수 있습니다. 또 계층의 추가로 인해 에러가 생길 가능성 그리고 시스템 유지보수의 난이도가 올라갈 수도 있겠죠.

사진: Building your own persistence model: the real state of affairs

실제로 Persicetence Model을 적용했을 경우 실제 애플리케이션의 복잡도가 생각보다 더 높아지는 경향이 있다고 합니다.

성능 오버헤드

DB 모델과 도메인 모델을 매핑하는 경우, 시스템 성능을 저하시킬 수 있습니다. 특히 매핑 방식이 최적화 되어있지 않은 경우, 높은 처리율과 빅데이터셋을 다루면 크게 성능이 저하됩니다.

모델 간 비일관성

경우에 따라 발현될 수도 있고 아닐 수도 있는 단점인 것 같습니다. 도메인 모델과 데이터베이스 모델을 분리하게 되면, 그 두 모델이 다르게 진화함에 따라 일관성이 유지되지 않는 문제가 생길 수 있습니다. 그렇게 되면 모델 간에 데이터를 매핑하거나 동기화하는 비용이 증가할 수 있습니다.

어떻게 결정해야할까?

간단하고 빠른 개발을 위해서는 데이터베이스 모델, 즉 persistence layer를 따로 두지 않는 것이 적절할 것입니다. 이런 경우 ORM 을 사용해서 데이터베이스 값을 도메인 모델에 한번에 매핑해 줄 수 있게 됩니다.

하지만 단단하고 풍부한 로직을 가진 도메인 모델을 유지하고 싶다면 순수 도메인을 위해 데이터베이스 레이어를 나누는 것이 적절할 것입니다.

결론적으로, 우리가 만드는 애플리케이션의 요구사항, 그리고 컨텍스트마다 고민해서 결정할 수 있어야합니다. 계층이 하나 더 생김으로써 얻는 혜택이 비용보다 더 큰지 비교해야 정할 수 있는 것이죠.