bearics
commented
3 years ago 7장 언어의 사용(확장 예제)
도메인 격리(응용 기능 소개) = layered architecture
- Tracking Query(추적 질의) : 특정 cargo의 과거와 현재 처리 상태 조회
- Booking Application(예약 애플리케이션) : new cargo 등록 & 등록된 cargo 처리 준비
- Incident Logging Application(사건 기록 애플리케이션) : 각 cargo 내역 기록
이 응용 계층의 클래스 = 조정자(coordinator)
ENTITY & VO 구분
Customer : ID 식별성 O > ENTITY
Cargo : 여러 Cargo 구분 필요. ID 식별성 O > ENTITY
Handling Event & Carrier Movement : 사건 구분 필요. 식별성 O > ENTITY
Location : 식별성 필요. > ENTITY
Delivery History* : Cargo와 일대일 관계라 식별성 필요?
Delivery Specification : > VO
도메인의 연관관계 설계
- Cago > Customer 관계인데, Repository를 이용해 다른 방향으로 접근 할 수 있다?
- class 간의 관계은 Cargo > Customer로 두고, DB select으로 반대로 접근 할 수 있다는건가?
- Location과 같은 기본적인 ENTITY는...
- 이것도 엔티티인가요?
- 이러한 관계들은 이상적인 설계도 중요하지만, 성능도 무시할 수 없음(포인터를 어디 클래스에 두느냐.. 등)
AGGREGATE의 경계
- customer, location, carrier movement 자체 식별성이 있고, 여러 cargo에서 공유되기에 자체 AGG의 루트
- cargo's AGG
- Delivery History, Delivery Specification : cargo가 없으면 의미 없는 것들은 같은 AGG로 묶기
- Handling Event : Carrier Movement의 이벤트를 조회해야 할 수 있어서 따로 빼는것이 좋을듯
REPOSITORY의 선정
- handling event는 delivery history의 컬렉션으로 유지 하기에 따로 REPO X
객체 생성
- Handling Event를 추가하게 되면, Cargo의 delivery History까지 업데이트 해줘야함.
이는 Handling Event 생성 과정에 Cargo까지 트랜잭션으로 묶여야 한다
- 이를 해결하기 위해 컬랙션 관계 > 질의로 교체 & Hadling Event REPO 추가
MODULE
업무 분야에 따라 관계에 따라 잘 나눠야 한다.
새로운 기능 추가
무슨 소리지..?
y2o2u2n
youngvly
책 내용 순서대로 요약한거 링크 볼 필요는 없음
생각
새로운 기능 추가하는게 인상적이고 이상적인 듯 우리가 저렇게 새로운 기능을 추가할 때 잘 할 수 있을까
읽기 힘들다..