도메인 객체와 DB 엔티티를 분리해야 하는 상황은 언제일까요?

[softmoca]

객체지향 설계에서 도메인 객체(Domain Object)와
DB 엔티티(Persistence Entity)를 분리해야 한다는 이야기가 자주 나옵니다.

하지만 모든 프로젝트에서 분리가 정당화되는 건 아닙니다.
도메인과 스키마가 거의 1:1이고, 변경 압력이 적은 경우에는
분리 자체가 오버 엔지니어링이 될 수 있죠.

여러분은 "분리해야 하는 상황"의 기준을 무엇이라고 보시나요?

• 어떤 조건(도메인 복잡도, 스키마 변경 빈도, 저장소 다양성 등)에서 분리가 정당화된다고 생각하시나요?
• 반대로, 분리하지 않고 극복할 수 있는 상황의 기준은 무엇인가요?
• 이번 미션에서 본인은 어떤 선택을 했고, 그 근거는 무엇이었나요?

[Uechann]

정말 깊게 고민해볼수 있는 주제라고 생각합니다.

왜 분리를 해야할까?

어떤 문제로 인해서 분리를 해야하는지에 대한 질문을 해볼 수 있다고 생각합니다.
분리를 해야하는 것에 문제는 관심사가 다른 두개의 영역의 결합을 끊게 되는 것이라고 생각합니다.
예시로 JPA entity와 java 도메인 객체 를 생각해본다면 다음과 같은 문제점들 생각할 수 있을거 같습니다.

1. 영속성에 대한 기술이 도메인을 침범한다.
   JPA에 대한 기술들이 도메인 클래스에 적용되고 도메인 구체적인 특정 기술에 종속되게 된다.

2. DB 스키마가 도메인의 설계를 주도하게 된다.
   DB에 지식, 사정들이 도메인 모델의 형태를 결정하게 된다.

3. 변경에 대한 전파가 양방향으로 일어나게 된다.
   비즈니스 규칙의 변경이, DB 스키마에 영향이 가게되거나,
   DB 스키마가 변경되면 도메인의 코드도 변경되게 된다.

분리해야 하는 상황은 무엇일까?

위에서와 같은 문제점들이 있기 때문에 분리를 하게 되는 거라고 생각이 드는데요,
그래서 분리를 해야하는 상황을 살펴본다면 다음과 같은 상황이 있을 수 있을거 같습니다.

1. 도메인에 대한 복잡도가 높다고 판단되는 상황
   비즈니스에 대한 로직이 두껍고, 도메인에 행위를 담아야 하는게 JPA에 대한 제약 때문에 불편할 때,

2. DB 스키마와 도메인이 1:1로 매핑이 되지 않을 때
   먼저 도메인에 대한 구조로 객체지향적으로 생각해보았을 때,
   한 도메인에 대한 개념이 여러 테이블에 흩어져 있거나, 반대로 여러 도메인의 개념이 한 테이블에 섞여 있을 때

[softmoca]

우와 제가 생각하고 정리한 내용과 거의 완전 똑같은것 같네요 !!

저도 우선 딱 위 두개의 상황이 떠올랐는데,
위 두 상황에 대해 직접 코드를 짜보지 않아서,
머리로는 이해했지만 크게 와닿지는 않는 상황입니다 !

그래서 추가로 두가지 상황을 만들 요구사항을 추가해서 선택미션 기간에 경험을 해볼까 하는데요 !
혹시 마이찬은 이전에 위 두가지 상황을 경험하신적이 있으신가요?!