해결된 질문
작성
·
95
2
안녕하세요. 영호님 좋은 책 그리고 그에 보충되는 강의를 정말 잘 읽고 있습니다. 책을 읽고 많은 교훈(역할, 책임 협력의 중요성)을 얻고 실무에 반영해보려했던 2년간의 경험이 있었습니다.
역할과 책임에 따른 객체에 따른 클래스 디자인을 설계하고 관계형 데이터베이스와 ORM 기술을 이용해서 설계를 진행할 경우 테이블이 많아지는 경향성이 있다고 느껴왔습니다.
DB 모델과 객체 모델은 달라야하는 걸까요? 아니면 같은 형태로 가도록 지향해야할가요? 비즈니스에 맞게 유연하게 진행해야하는 것은 알지만 여기서 "유연하게"가 모델과의 일치를 지향하면서 최적화를 해나가야하는건지 조영호님의 경험과 의견이 궁금합니다.
(질문이 제대로 전달되는지 모르겠네요.)
답변 2
2
지호선님 안녕하세요.
먼저 좋은 질문 남겨주셔서 감사합니다. :)
개인적으로 특별한 경우가 아니라면 ORM의 엔티티를 도메인 클래스로 사용하는 쪽을 선호하는데 jpa를 사용하는 경우 퍼시스턴스 처리에 대해에서 간단히 설명드렸으니 해당 질문을 참고해 주시면 감사하겠습니다.
이렇게 ORM 엔테티를 도메인 클래스로 사용하는 경우에는 (정규화 원칙에 다소 위배되더라도) 데이터베이스 테이블을 도메인 클래스에 매핑하기 쉬운 방식으로 설계하는 편입니다.
하지만 클래스 설계와 테이블 설계는 기반을 두고 있는 패러다임 자체가 다르기 때문에(임피던스 불일치) 완전히 동일한 형태로 설계할 수는 없습니다.
데이터베이스 설계는 데이터의 중복을 최소화하는 관점에서 접근하기 때문에 입도가 크지만 클래스는 행동 관점에서 접근하기 때문에 입도가 작습니다.
따라서 JPA의 Embeddable을 이용해서 엔티티와 값 객체를 하나의 테이블에 함께 저장하는 경우처럼 테이블을 클래스에 매핑할 경우에는 하나의 테이블에 여러 개의 클래스를 매핑하는 것이 일반적입니다.
특히 다형성을 활용하기 위해 상속을 사용하는 경우에는 유지보수와 쿼리의 편의성을 위해 단일 테이블 방식으로 매핑하는 것이 일반적인데 이 경우 상속 계층에 속하는 다수의 클래스를 하나의 테이블에 매핑시킵니다.
결론적으로 데이터베이스 설계와 객체 설계 각각의 지향점은 다르기 때문에 다를 수 밖에 없습니다.
ORM이 모든 매핑 이슈를 해결해 주지는 않기 때문에 데이터베이스 설계와 객체지향 설계 관점에서 어느정도 타협을 할 수 밖에 없고, 결과적으로 각각의 설계 관점에서 최적은 아닐지라도 양쪽 모델을 직관적으로 매핑할 수 있는 구조를 선택하는 것이 현명하다고 생각합니다.
답변이 되었는지 모르겠네요. 🙂
1
답변 감사합니다! .NET 생태계에서 개발을 해서 개념적 동치인 기술들로 치환해서 잘 이해를 했습니다. e.g. JPA의 Embeddable <-> EF Core의 Owned Entity Types
데이터베이스 설계는 데이터의 중복을 최소화하는 관점에서 접근하기 때문에 입도가 크지만 클래스는 행동 관점에서 접근하기 때문에 입도가 작습니다.
"입도" 라는 하나의 개념을 담는 그릇의 크기 정도로 이해하면 되겠네요. (그 느낌을 표현하기 쉽지않았는데 좋은 표현인 것 같음)
말씀하신 "결과적으로 각각의 설계 관점에서 최적은 아닐지라도 양쪽 모델을 직관적으로 매핑할 수 있는 구조를 선택" -> 도메인 주도 개발 공부를 하면서 데이터 구조 또한 도메인 모델을 대변할 수 있어야한다는 내용이 생각이나네요. 궁금증은 많이 해소 됐습니다. 궁금증이라기 보다는 유사한 생각임을 확인해서 마음이 편하네요.