본문 바로가기

연관11

DDD - S/W와 모델 - 출처: 도메인 주도 설계 - 에릭 에반스 - S/W 에서 표현되는 모델 S/W 에서는 모델을 표현하는 주요 패턴으로 3가지 형태가 주로 사용된다. Entity: 어떤 객체가 영속성과 식별성을 지닐 때 VO: 다른 무언가의 상태를 기술하는 속성에 불과할 때 Service: 객체보다 행동/연산으로 더 명확하게 표현되는 경우 자바라면 class, Golang 이라면 struct로 표현하기만 하면 되는데 왜 굳이 Entity와 VO라는 개념을 도입해서 나누는지 의문을 가질 수도 있다. 굳이 이렇게 하는 이유는 특정 객체가 특정 패턴을 따르면 객체의 역할이 더욱 명확해져서 설계 결정을 하는데 도움이 되기 때문이다. Entity와 VO만 있으면 객체를 표현할 수 있는데 Service라는 개념은 왜 필요할까? .. 2022. 7. 16.
객체지향의 사실과 오해 - 기능과 구조의 통합 - 이 글은 조영호의 객체지향의 사실과 오해를 기반으로 작성되었습니다. (가능하면 꼭 읽어보는것을 추천드립니다.) - 도메인 모델, 유스케이스 그리고 책임-주도 설계 시스템이라는 것은 사용자가 첫번째로 만나게 되는 객체이다. 사용자 입장에서 시스템은 자신과의 협력에서 자신의 요청을 처리하는 하나의 객체로 볼 수 있다. 시스템은 자신안에 더 작은 객체들을 갖고 있으며, 사용자로부터 받은 책임을 더 작은 객체들로 적절하게 분배해야 한다. 여기에서 책임-주도 설계가 등장한다. 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 볼 수 있게 한다. 즉 사용자로 부터 처음으로 메시지를 수신하는 출발점의 역할을 한다. 그 이후에는 시스템이 안정적인 도메인 모델에 기반하여 기능을 수용하고 객체들로 책임을 분배한다.. 2021. 8. 28.
JPA - 다양한 연관관계 - M : N - 참조: 자바 ORM 표준 JPA 프로그래밍 - M : N 관계 회원과 상품이 있다고 가정해보자. 회원은 여러 상품을 주문할 수 있고, 하나의 상품도 여러 회원들에 의해 주문될 수 있다. 이때 다중성의 관계는 M : N 이다. 이를 ER Diagram 으로 나타내면 위와 같다. 그러나 RDB(관계형 DB)는 정규화된 테이블 2개로 다대다 관계를 표현할 수 없다. 그래서 조인 테이블을 사용한다. 1 번째 다이어그램에서 USER 와 PRODUCT 의 PK인 USER_ID 와 PRODUCT_ID 로 이루어진 조인테이블 USER_PRODUCT 가 추가되었다. 하지만 객체의 경우에는 서로에 대해 M : N 을 나타낼 때 조인객체를 두지 않는다. 위 다이어그램처럼 다대다 관계에서 회원은 상품을, 상품은 회원을 컬.. 2021. 7. 8.
JPA - 다양한 연관관계 - 1 : 1 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 1 : 1 연관관계 1 : 1 관계는 양쪽이 서로 하나씩만 가지는 관계로 아주 심플한 다중성을 갖는다. 회원과 사물함이 있다고 할 때, 회원은 하나의 사물함만 소유할 수 있고 사물함도 회원 한명에 의해서만 소유될 수 있다고 한다면 1 : 1 관계이다. 다중성에서 항상 N 쪽이 외래키를 가진다고 하였는데, 1 : 1 에서는 어느쪽에 외래키를 두어도 되기 때문에 양방향일 경우 연관관계의 주인을 선택해야 한다. 주 테이블 또는 대상 테이블에 외래키를 둘 수 있다. 주 테이블: 주 테이블에 대상 테이블을 참조하는 사상을 그대로 따라가기 때문에 어플리케이션 코드에 더 직관적이다. 대상 테이블: DB 개발자들이 선호하는 방법이며 1 : 1 에서 1 : N 으로 변경.. 2021. 7. 6.
JPA - 다양한 연관관계 - N : 1 과 1 : N - 참조: 자바 ORM 표준 JPA 프로그래밍 - 다양한 연관관계 앞에서 몇 가지 예제를 통해 연관관계를 작성해보았다. JPA 에 익숙하지 않다면 JPA를 사용하여 연관관계 코드를 작성하는게 헷갈릴 수 있다. 이때에는 연관관계 맵핑시 고려할 사항을 순차적으로 정해놓고 천천히 생각해보면 좀 더 수월하다. 다중성: N : 1 인지 1 : N 인지에 따라 @ManyToOne, @OneToMany 어떤 다중성 어노테이션을 사용할 지 정한다. 단방향, 양방향: 하나의 엔티티가 다른 엔티티를 참조하는지 서로 참조하는지를 정한다. 연관관계의 주인, 연관관계 편의메소드: 양방향이라면 두 엔티티중 외래키를 관리할 연관관계의 주인과 연관관계 편의메소드 작성을 고려한다. - N : 1 단방향 회원 엔티티와 팀 엔티티가 있다.. 2021. 7. 3.
JPA - 연관관계 맵핑 - 연관관계 맵핑 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 외래키에서 참조로의 변환 지난번 요구사항을 Entity 로 변환하는 과정에서 아래 다이어그램과 같이 속성으로 외래키를 그대로 냅두었었다. 연관관계 맵핑을 배웠으니 이 외래키들을 참조로 변환할 수 있다. 연관관계를 더 명확히 보기 위해서 해당 필드에도 다중성을 표시하였다. 아래 설명은 위의 다이어그램에서 클래스간의 관계를 파악한것이다. Member - Order: 멤버는 주문을 1건도 하지 않을 수도, 여러건을 할 수도 있다. 1 : N 의 관계이다. Member 와 Order 는 서로간을 참조하는 양방향 연관관계이다. 외래키는 Order 에서 MEMBER_ID 를 가져야 한다. 앞에서 설명했듯이 Member : Order = 1 : N 이므로 N 쪽에서 .. 2021. 7. 2.
JPA - 연관관계 맵핑 - 양방향 연관 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 양방향 연관관계 이전 예제에서는 회원에서 팀으로 접근하는 단방향 연관관계를 알아보았다. 이번에는 팀에서 회원으로 접근할 수 있는 양방향 연관관계를 맵핑해본다. 위 다이어그램에서 회원과 Team은 다대일 연관관계이다. 회원은 아직 팀에 속해있지 않을 수도 있고, 1개팀에 속할수도 있지만 2개 이상팀에는 속할수가 없기 때문에 다중성의 하한과 상한은 0..1이다. 반면 팀은 여러명의 멤버들로 구성될 수 있기 때문에 다중성을 * 이며, Type은 User 이다. DB 입장에서는 달라지는 내용이 전혀 없다. 어차피 외래키 하나로 Join 하면 되기 때문에, 기존의 형상을 유지한다. User 는 이전소스와 달라지는것이 없다. Team 에서 User 를 참조하기 위한.. 2021. 7. 1.
JPA - 연관관계 맵핑 - 단방향 연관 - 참조: 자바 ORM 표준 JPA 프로그래밍 - 연관관계 대부분의 엔티티들은 다른 엔티티와 관계가 있다. 주문은 상품과, 상품은 카테고리등 다른 엔티티와 관계를 갖는다. JPA 를 사용시 관계설정의 핵심은 객체 와 DB 가 다른 엔티티들과 관계를 맺을 때 연관방식이 다른다는데에 있다. DB 에서 다른 엔티티를 참조할 때 외래키를 사용하는데 JPA 를 이용하여 어플리케이션에서 어떻게 나타낼지 알아보자. 본격적으로 알아보기전 연관과 관련된 핵심 키워드를 알아본다. 방향: 단방향과 양방향이 있다. 만약 멤버가 주문을 참조하기만 하면 단방향이며, 만약 주문도 멤버를 참조한다면 양방향 관계이다. 다중성: 1:1, 1:N, N:1, M:N 관계를 나타낸다. 만약 어플리케이션에서 "회원은 여러 주문을 할 수 있으며.. 2021. 6. 30.
UML - 클래스 다이어그램 고급 - 연관 클래스 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 연관 클래스(Association class) 연관 클래스는 클래스간 연관 관계에 속성, 오퍼레이션 그리고 다른 기능들을 더해줄 수 있도록 해준다. 어떤 사람(Person)이 회의(Meeting)에 참석(Attendance)하는 다이어그램을 한번 살펴보자. Person과 Meeting 연관 관계에 Attendance 연관 클래스를 더했다. 또 연관 클래스에는 참석 여부를 가리키는 attentiveness 속성을 더했다. 사실 연관 클래스를 사용하지 않아도 우리는 이 관계를 표현할 수 있다. 연관 클래스가 아닌 완전한 클래스로 변환하여 위와 같은 다중성을 표시해주면 의미가 같아진다. 다중성을 변환한 부분이 좀 헷갈릴 수 .. 2021. 2. 10.
UML - 클래스 다이어그램 고급 - 한정 연관 - 이 글은 UML Distilled (마틴 파울러)책을 기반으로 작성하였습니다. - 한정 연관(Qualified association) 한정 연관은 UML 에서 관계 배열, 맵, 해시, 딕셔너리로 표현할 수 있다. 위 다이어그램은 Order 클래스와 OrderLine 클래스 사이의 관계를 Product를 이용하여 한정자(Qualifier)를 표시한것이다. 여기서 Product 의 인스턴스는 각 하나의 OrderLine 만 존재한다는것을 표현한다. 한정 연관에서 다중성을 잘 해석해야 한다. OrderLIne 의 0..1 다중성은 Product에 대한 것이지 Order에 대한것이 아니다. Order 는 여러 개의 OrderLine 을 가질 수 있더라도 위의 다이어그램에서 다중성 상한 1(0..1)이 나타내.. 2021. 2. 10.