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

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가 거의 동일한 경우가 많아서, 둘을 분리하는 것이 불필요한 작업처럼 느껴지기 때문이다¹.
• ORM @Entity와 Domain Model을 동일시 하면, domain module과 persistence module(ORM 한정)을 분리 할 수 없다. 하나로 구성해야 한다.

결론

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은 원칙적으로 Pure 해야 하므로, Domain Model의 본질을 해치지 않는 선에서 이루어져야 한다.
• ORM은 다양한 애너테이션을 지원한다.
  • Spring data jdbc에서 ID 미리 채번하는 경우
  • @BatchSize를 @Entity에 붙이는 경우

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

참고

• Repository와 DAO의 차이
• 프로젝트 상황에 따라서 각각의 트레이드 오프를 고민하고 선택해야 합니다.
• https://web.archive.org/web/20150320062723/https://vaughnvernon.co/?p=879
• https://stackoverflow.com/questions/51564704/ddd-entity-in-orm-and-java
• https://stackoverflow.com/questions/61541229/aggregate-to-jpa-entity-mapping
• https://stackoverflow.com/questions/65020267/jpa-entity-as-domain-model
• DDD 지향 마이크로 서비스 디자인 - .NET
• NFC 사례

ORM @Entity 네이밍 규칙

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

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