서론

공부 할 내용

공부 환경

장소: 동대문 할리스

시간: 월요일 퇴근후

향기: 흡연실 바로 앞 목과 폐가 아플 정도의 담배향기

들었던 음악

본론

1장. 도메인 모델 시이작!

도메인이 뭐지? 

소프트웨어로 해결하고자 하는 문제의 영역. 

예를 들어 주겠어요? 

• 온라인 서점은 도메인이고요! 이 도메인은 또 주문, 배송, 결제와 같은 도메인으로 나뉩니다. 꼭 도메인을 우리가 다 구현해야할 필요는 없고 외부 pg사 연동같이 구성할 수도 있습니다. 

도메인 모델?

특정 도메인을 개념적으로 표현한 것. 도메인 자체를 이해하기 위한 개념 모델.

어떻게 모델로 표현하나?

• 각자 방법에 맞게끔.
• 객체 모델(클래스 다이어그램) 일수도 있고. 그럼 객체 지향 언어를 통해서 구현하면 편하구..
• 상태 다이어그램으로 작성할 수도 있고
• 계산이 중요하다면 수학 공식을 활용해서 function으로 구현하던지
• 관계가 중요하면 그래프를 이용해도 되고

걍 이해가기 쉽게 표현하는 거시라고 이해했다 ^_^ 

구현 모델은 또 따로 필요하다. 

도메인 모델 패턴

아키텍처는 표현/응용/도메인/인프라스트럭쳐 4개의 계층으로 구성되어있는 것이 일반적, 여기서의 도메인 모델은 PEAA 책에 따르면, 아키텍처 상 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 뜻함.

즉, 각 계층별로 뭘 구현해야하냐 인데, 도메인 모델 패턴은 도메인 계층을 어떻게 구현하는지.

도메인 구현 = 도메인의 핵심 규칙 구현

• e.g., 출고 전에만 배송지를 변경할 수 있음. 
• 주문 취소는 배송 전에만 할 수 있음

도메인 모델 도출

요구사항을 정리해서 도메인 규칙을 만들어 낸 다음에 구현한다.

엔티티와 밸류

엔티티

• 식별자를 갖는다.
• 삭제할때까지 변경하던 식별자는 유지됨
• 두개 엔티티의 식별자가 같으면 두 엔티티는 같다.
• e.g) 주문번호가 같으면 같은 주문임
• equals(), hashCode() 메소드를 가짐
• 생성 시점이나 방법은 도메인 특징 별로 다름
• 특정 규칙을 쓰거나
• UUID 클래스를 쓰거나
• 아이디 같이 직접 입력하거나
• 일련 번호를 쓰거나(mysql aI key..)
• 생성하기 전에는 식별자 전달 불가

밸류 타입

• 개념적으로 완전한 하나를 표현하고자 할 떄
• e.g.) 받는 사람 + 주소를 묶어서 Receiver,
• e.g.2) price를 뜻하는 money 타입
• 장점: 
• money를 위한 기능을 만들 수 있음. 돈계산같이..!
• 어떻게 변경하나?
• 기존을 변경하는게 아니라 새로운 밸류를 생성함.
• 이뮤터블(불변)
• 모든 속성이 같은지 비교해야 두 밸류 객체가 같은지 알 수 있음

엔티티 식별자와 밸류 타입

• 식별자를 위한 밸류타입을 사용해서 활용 가능

도메인 모델에 set을 넣지말자? 왜?

• set이 어떤 의미인지 개념이나 의도가 없어진다
• 생성할때 완전한 상태가 아닐 수도 있다. (생성한담 셋하는데 뭐 하나 빼먹으면 어쩔꺼야? 그냥 생성할떄 다 받아라)
• 프라이빗으로 생성할때 set시키도록. 외부에서 set 불가하고.. 

도메인 용어

• step1, step2가 아닌 payMENT_WAITING, PREPAREING 등 도메인에서 사용하는 용어를 써라

2장. 아키텍쳐 개요

네개의 영역

표현

• 응용에 변환하여 전달하고 받은 응답을 변환하여 웹브라우저에 보여주고

응용

• 표현 영역을 통해 받은 걸 처리하기 위한 기능을 구현
• 구현하기 위해 도메인 영역의 도메인 모델 사용(도메인 모델에 로직 수행 위임)
• 주문등록, 주문 취소, 상품 상세 조회

도메인

• 도메인 모델 구현(1장 내용)
• 배송지 변경, 결제완료, 주문 총액 계산

인프라

• 구현 기술에 대한 것
• RDBMS, 메시지 큐, SMTP, REST API… 

계층 구조 아키텍처

전형적인 계층 구조상의 의존 관계를 가지면 생기는 문제들(상위 계층에서 하위 계층으로 의존)

• 테스트 어려움 (인프라 레벨 룰엔진이 완벽하게 동작해야 응용 영역에서 계산을 할 수 있음)
• 기능확장 어려움(구현 방식을 변경하기 어렵다.) 

DIP

고수준: 가격 할인 계산 저수준: RDBMS로 JPA 구현, Drools로 룰 적용

DIP: 저순준 모듈이 고 수준 모듈에 의존하도록 바꿈. 어떻게? 추상화한 인터페이스로!

RuleDiscounter라는 인터페이스를 만들어서 고수준은 ruleDiscounter를 활용하고, 저수준은 ruleDiscounter를 상속받아 구현. 

왜 쉬워지는 거지?

• 테스트해본다면? 
• 저수준 안만들고 대용 객체를 사용해서 테스트 진행 가능 (목 데이터 활용)
• 구현 기술이 변경된다면?
• 고수준쪽은 수정안하고 저수준 구현 객체 생성하는 부분의 코드를 변경한다. (ruleDiscounter를 생성하는 애만 바꿈..)

DIP와 아키텍처

?? 잘 이해는 안가는 데 여튼 인프라가 응용 쪽의 인터페이스를 상속 받고 있으니 응용 영역 변경할 필요가 없고 notifier를 구현하는 클래스를 인프라에다가 추가하면 되니까 깔끔하다는 것 같다? 

도메인 영역의 주요 구성 요소

• 엔티티
• 밸류
• 애그리거트
• 리포지터리
• 도메인 서비스