Post

ORM @Entity를 Domain Model로 써도 될까?

Posted Updated
By umbum 5 min read

ORM @Entity를 Domain Model로 써도 될까?

pros and cons

  • 원래 Domain Model은 persistence와 무관하며, Pure해야 한다
    • Domain이 가장 높은 우선순위를 가지며 설계의 중심이 되는 것이 맞다.
    • ORM을 쓰다가, 걷어내고 단순 쿼리 실행기(e.g., JDBC)로 변경해도 Domain 설계가 변경되어서는 안된다.
    • 즉, persistence framework로 ORM을 쓰는지 안쓰는지가 Domain layer에 영향을 주어서는 안된다.
  • 그러나 Domain Model과 ORM @Entity를 완전히 분리하는 것은 어렵다. 실제로 Domain Model과 ORM @Entity가 거의 동일한 경우가 많아서, 둘을 분리하는 것이 불필요한 작업처럼 느껴지기 때문이다1.
  • ORM @Entity와 Domain Model을 동일시 하면, domain module과 persistence module(ORM 한정)을 분리 할 수 없다. 하나로 구성해야 한다.

결론

1
2
3
4

if (DB 컬럼과 Domain Model에서 요구하는 필드가 동일한 경우)
    ORM @Entity를 Domain Model로 사용
else (불일치하는 경우)
    ORM @Entity와 Domain Model을 분리
  • Domain Model는 Pure한 것이 원칙이나, 동일한 필드를 가진 클래스를 한 벌 더 만들어야 한다는 데서 오는 피로감을 고려해서, Domain Model에 ORM @Entity를 붙이는 것은 제한적으로 허용
    • 비즈니스에서 ORM @Entity를 직접 사용하는 경우와 Domain Model을 사용하는 경우 모두 허용
  • ORM @Entity가 아닌 기타 애너테이션은 Domain Model에 부착 불가
  • 특히 아래 케이스에 해당한다면 도메인 모델을 분리한다.

ORM @Entity와 Domain Model을 분리해야 하는 신호

가장 중요한 것은 [persistence layer → domain layer] 방향으로 변경 압력이 가해져서는 안된다는 점이다.

table schema가 잘못 설계된 경우

  • ORM @Entity를 그대로 Domain Model로 쓰게 되면, 잘못 설계된 table 구조가 그대로 Domain layer에 노출된다.

⇒ ORM @Entity와 Domain Model을 분리해서, 잘 설계되지 않은 못생기고 지저분한 table schema는 persistence layer에서 추상화한다.

갱신 이상을 피하기 위해 컬럼이 누락된 경우

  • DB 설계는 갱신 이상을 피하기 위해 중복을 최대한 제거하기 때문에, 이로 인한 ORM @Entity <> Domain Entity 불일치가 발생할 가능성이 높다.
  • @Entity는 table column과 동일하게 필드를 구성하게 되는데. 도메인 모델에는 column에는 없어야 하는 필드나 더 있어야 하는 필드가 종종 존재하게 된다.
  • 물론 table에는 없고 비즈니스에서는 필요한 필드에 대해서 @Transient 사용이 가능하지만… 애매하다.

⇒ 이런 불편이 도메인 모델에 대한 잘못된 변경 압력으로 작용하지 않도록, ORM @Entity와 Domain Model을 분리한다.

persistence 전용 애너테이션으로 인한 Domain Model 오염이 과도한 경우

⇒ 애너테이션이 과도하게 붙는다면, ORM @Entity와 Domain Model 분리 필요한지 검토해본다.

참고

ORM @Entity 네이밍 규칙

  • XxxEntity는 도메인 모델의 Entity와 겹칠 수 있음.
  • XxxRow는 presentation의 표나 엑셀과 겹칠 수 있음.
  • XxxRecord가 가장 시인성이 좋아보임.



  1. 그래서 직접 정의한 도메인 모델은 없고, 오직 ORM @Entity만을 도메인 모델로 쓰는 것을 고집하는 경우가 종종 보인다. (안티패턴) ↩

0System Design, Layered Architecture
ORM
This post is licensed under CC BY 4.0 by the author.