07 - 언어의 사용(확장 예제) (1)
Last updated
Last updated
고객 화물의 주요 처리상황 추적
화물 사전 예약
화물이 일정한 처리 시점에 도달할 때 자동으로 고객에게 송장을 발송
Handleing Event(처리 이벤트) : Cargo 에 불연속적으로 발생하는 활동(화물을 배에 적재, 세관 통과 등등 .. )
Delivery Specification(배송 명세) : 목적지와 도착 날짜를 포함한 배송 목표를 정의
Delivery Specification 이 없다면 Cargo 객체에서 배송 목표를 명시하기 위한 모든 속성과 연관관계의 세부적인 의미를 책임져야 한다.
추상화를 통해 전체적으로 모델을 설명할 떄 세부사항을 쉽고 안전하게 감출 수 있다.
더 표현력이 있다. Cargo 의 정확한 배송 수단이 결정되지 않았지만 Delivery Specification 에 명시된 목표는 반드시 달성해야 한다는 점을 명시적으로 드러낸다.
Carrier Movement : 특정 Carrier 에 의한 한 Location 에서 다른 Location 으로의 이동
Delivery History(배송 이력) : 실제 화물에 어떤 일이 발생했는지를 반영
Tracking Query(추적 질의) : 특정 화물의 과거와 현재 처리 상태에 접근
Booking Application(예약 어플리케이션) : 새로운 Cargo 를 등록하고 등록된 화물 처리를 준비
Incident Logging Application(사건 기록 어플리케이션) : 각 Cargo 의 처리 내역을 기록 (Tracking Query 로 찾은 정보를 제공)
Entity, Value Object 구분
Entity : 고유한 식별자를 가지며, 시스템 내에서 독립적인 생명주기를 갖는 객체이다. 일반덕으로 DB 의 테이블과 일대일로 매핑되며, 상태를 가지고 변경될 수 있다.
Value Object : 상태만을 표현하며, 고유한 식별자를 가지지 않는다. 불변성을 가지고, 전체적으로 하나의 개념을 나타낸다. ex, 주소, 금액, 색상
Customer(고객) : Customer 는 한 사람이나 회사를 나타내는 ENTITY 이다. 고객 데이터베이스를 통해 고객의 ID 를 할당한다 .
Cargo(화물) : 각각 화물에 해당하는 ENTITY 이다. 화물 ID 는 자동으로 생성되며, 예약 시 고객에게 전달된다.
Handling Event(처리 이벤트), Carrier Movement(운송수단 이동) : 개별 사건을 토대로 처리 상황을 알아낼 수 있다. 현실 세계에서 사건이 개별로 존재하므로 ENTITY 이다.
Location(위치) : 경도, 위도같은 속성을 키로 삼을수는 있지만, 실용적인 방법은 아니다. 오히려 해운 항로를 비롯한 도메인에 특화된 관심사에 따라 장소를 관련지을 수 있다. 따라서 임의의 내부 식별자만으로 충분하다.
Delivery History(배송 이력) : Delivery History 는 서로 대체할 수 없으므로 ENTITY 에 해당하지만, 화물과 1:1 관계에 있으므로 자체적인 식별성은 없다. Delvery History 의 식별성은 그것을 소유하는 Cargo 에서 가져온 것이다.
Delivery Specification(배송 명세) : Delivery Specification 은 Cargo 의 목표를 나타내긴 하지만, Cargo 에 의존하지는 않는다. 두 개의 Cargo 가 동일한 곳으로 배송되는 중이라면 동일한 Delivery Spesification 을 공유할 수 있다. 따라서 VALUE OBJECT 이다.
역할과 그 밖의 속성 : 역할은 연관관계에 관한 사항을 전달하지만, 이력이나 연속성을 지니지는 않는다. 따라서 역할은 VALUE OBJECT 이다. 시간/날짜나 이름 같은 그 밖의 속성은 VALUE OBJECT 이다.
Customer 와 Location, Carrier Movement 는 자체적인 식별성을 지니고, 여러 Cargo 사이에서 공유되므로 자체적인 Aggregate 루트가 되어야 한다. Aggregate 에는 그것들의 속성을 비롯해 상세 수준의 다른 객체도 포함된다.
Cargo Aggregate 는 특정 Cargo 가 없다면 존재하지 않을 것들을 포함할 수 있다.
Delivery History, Delivery Specification, Handler Event 가 이에 속한다.
Handler Event 도 자체적인 Aggregate 의 루트이다.
Delivery History 에 대한 Handler Event 를 찾거나, Carrier Movement 를 적재 및 준비하기 위한 활동을 찾는데 사용할 수 있다.
Aggregate 의 루트인 Entity 가 5개가 있으므로 여기에 맞게 고려사항을 한정할 수 있다 .
어떤 것이 실제 Repository 를 가져야하는지 결정하기 위해 애플리케이션의 요구사항을 되돌아 볼 필요가 있다.
화물을 예약하려면 다양한 역할(선적인, 수하인 등) 을 수행하는 Customer 를 선택해야 하므로 Customer Repository 가 필요할 것이다.
Cargo 의 목적지를 지정하고자 Location 을 찾아볼 필요가 있으므로 Location Repository 도 만들어야 한다.
사용자가 현재 Cargo 에 적재되고 있는 Carrier Movement 를 찾기 위해서는 Carrier Movement Repository 가 필요할 것이다.
어느 Cargo 에 적재됐는지 시스템에 알려주기 위해서 Cargo Repository 도 필요할 것이다.
Handling Event Repository 는 아직 없다. 이는 Delivery 와 관계를 컬렉션으로 구현하기로 했고, 애플리케이션 요구사항에 Carrier Movement 에 적재된 것을 찾아야 한다는 요건이 없기 때문이다.
