3. ㅊ
여러 고객은
(각각 다른 역할을 수행하는)
하나의 화물과 관계
화물의 배송 목표를 명시
명세에 따르는
운송 수단의 종류로
배송 목표를 달성
4. Handling Event
Handling Event는 Cargo
가 받는 불규칙적 이벤트이
다.
적재, 하역... 같은 이벤트를
발생시킨다.
5. Delivery Specification
배송 명세에는 배송 목표를
정의.
Cargo와 DS를 분리하는 장
점
배송목표관련 세부 사항/변
경/이해 힘듦
쉽고 세부사항을 감춤
6. Customer and Cargo
Role은 고객의 행위로 구분.
(선적인/수취인/지불인)
하나의 Customer은
특정 Cargo의 역할과
연관됨.
Role은
String, Class로 구현.
7. Carrier Movement
화물의 운송 이동.
화물은 여러번의
운송 이동이 발생하며,
운송 수단(트럭/배)은
교체될 수 있다.
8. Delivery History
배송 명세(목표)와 다르게,
화물의 위치/상황등
이력을 보여줌.
성공적으로 배송되면,
DH의 마지막 이력과
DS는 같아진다.
9. 도메인 격리:응용 기능 소개
Layered Architecture
를 적용.
추적 질의
Tracking Query,
예약 APP Booking Application,
Incident Logging App
사건 기록 APP classes 는
직접적인 작업을
수행하지 않고,
각 도메인 레이어에서
수행하도록 한다.
10. Entity와 Value Object의 구분
Customer - Entity
Cargo - Entity
Handling Event와 Carrier Movement - Entity
Location - 식별자로 작성
Delivery History - Entity
Delivery Specification - Value Object
Role/시간/날짜 - Value Object
11. 배송 도메인의 연관관계 설계
연관 설정은 모델에 대한
더 깊이 있는 통찰력을 제공한다.
양방향 연관은 문제가 된다.
12. 연관관계 설정 Customer는
대체로
여러 객체와 연동되는
역할을 가짐.
Customer에서 Cargo로 연
관되면, Customers 모두 반
복적으로 연관됨(???)
따라서, Cargo 에서
Customer로 연관시킨다.
Customer를 이용하여
Cargo를 찾는 경우
Repository 방식을 적용함.
13. 연관관계 설정
배송에 대한 정보를
추적한다면,
Carrier Movement 에서
Handling Event 로
연관되어야 하지만,(???)
화물을 추적해야 하므로,
HE에서 CM로 연관을 만든다.
(???)
14. 연관관계 설정
순환 참조는
필요할때도 있고
사용도 되지만,
유지보수를 어렵게 만듦.
동일한 정보를 2곳의 객체에
보관하지 않도록 구현.
자바 컬렉션등
단순한 수준에서 구현하거나,
데이터베이스로 구현가능.
(성능과 유지보수의
trade-offs)
15. AGGREGATE 의 경계
Customer, Location,
Carrier Movement 는
AGGREGATE 루트.
DH, DS, HE는
Cargo에 종속되므로
Cargo AGGREGATE에
포함 시킴.
16. REPOSITORY 의 선정
Entity만 Repository를 가짐.
예약 App은
Customer, Location 을
사용하므로 각각의 Repo 필요.
추적 질의 ALA 은 Cargo, CM을
예약 APP 사용하므로 각각의 Repo 필요.
사건 기록 APP
17. 시나리오 연습
예제 어플리케이션 기능 : 화물의 목적지 변경
DS은 Value Object이므로
새로운 DS를 생성하여 교체함.
18. 시나리오 연습
예제 어플리케이션 기능 : 반복 업무
기존 Cargo 정보를 계속 사용할 경우,
REPO에서 기존 Cargo 정보를 찾고,
Prototype Pattern을 이용하여
새 Cargo를 생성하도록 함.
Delivery History는 새로 생성함.
Customer Roles 은 동일하게 사용하는데, Customer는 복사
하지 않아야 함.
Tracking ID 는 새로 생성해야 함.
20. 객체 생성
Handling Event 추가
HE 는 Entity이므로 모든 속성이 생성자에 전달.
각 이벤트 타입에 대한 Factory Method를 추가.
21. 리팩터링할 시간 : Cargo AGGREGATE의
설계 대안
HE 추가할 때, Cargo
를 통해 DH가 갱신.
여러 사용자가 참여하
는 경우 트랜잭션 처리
가 필요.
Collection보다
데이터베이스를 이용.
22. 배송 모델의 모듈화
3개의 사용되는 형태로
(Entities, Values,
Services)
구분하는 경우,
응집도가 떨어지고,
모듈간 높은 결합도.
23. 도메인에 근거한 모듈
이 모듈 설계는
팀내 사용언어(Customer,
Shipping, Billing) 반영함.
Our company does shipping for
customers so that we can bill them.
Our sales and marketing people deal
with customers, and make
agreements with them.
The operations people do the
shipping, getting the cargo to its
specified destination.
The back office takes care of
billing, submitting invoices
according to the pricing in the
customer's agreement.
24. 새로운 기능 도입: 할당량 검사
예약 시스템에서 예약 수락 여부를
설정할 수 있도록 기존 시스템과 통합.
Cargo Repository와 Sales Management
System 에 질의후 수락여부를 결정.
25. 두 시스템의 연계
SMS은 기존 사용 시스템이고,
현재 시스템에 추가하려면,
MODEL-DRIVEN DESIGN, UBIQUITOUS
LANGUAGE에 혼란.
현재 시스템과 SMS 사이의 중간 클래스를 만들고,
필요한 기능만 노출하여 도메인관점에서 재추상화.
26. 모델 강화 : 업무 분야 나누기
Enterprise Segment 라는
부가적인 Value Object로
추가.
Allocation Checker는
ES와 SMS간 번역을 수행.