• Save
DDD-07-Using The Language
Upcoming SlideShare
Loading in...5
×
 

DDD-07-Using The Language

on

  • 540 views

 

Statistics

Views

Total Views
540
Views on SlideShare
540
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DDD-07-Using The Language DDD-07-Using The Language Presentation Transcript

  • 07 언어의 사용 (확장 예제)
  • 화물 해운 시스템 소개초기 요구 사항 고객 화물 추적 화물 예약 송장 발송
  • ㅊ 여러 고객은 (각각 다른 역할을 수행하는) 하나의 화물과 관계 화물의 배송 목표를 명시 명세에 따르는 운송 수단의 종류로 배송 목표를 달성 View slide
  • Handling Event Handling Event는 Cargo 가 받는 불규칙적 이벤트이 다. 적재, 하역... 같은 이벤트를 발생시킨다. View slide
  • Delivery Specification 배송 명세에는 배송 목표를 정의. Cargo와 DS를 분리하는 장 점 배송목표관련 세부 사항/변 경/이해 힘듦 쉽고 세부사항을 감춤
  • Customer and Cargo Role은 고객의 행위로 구분. (선적인/수취인/지불인) 하나의 Customer은 특정 Cargo의 역할과 연관됨. Role은 String, Class로 구현.
  • Carrier Movement 화물의 운송 이동. 화물은 여러번의 운송 이동이 발생하며, 운송 수단(트럭/배)은 교체될 수 있다.
  • Delivery History 배송 명세(목표)와 다르게, 화물의 위치/상황등 이력을 보여줌. 성공적으로 배송되면, DH의 마지막 이력과 DS는 같아진다.
  • 도메인 격리:응용 기능 소개 Layered Architecture 를 적용. 추적 질의 Tracking Query, 예약 APP Booking Application, Incident Logging App사건 기록 APP classes 는 직접적인 작업을 수행하지 않고, 각 도메인 레이어에서 수행하도록 한다.
  • Entity와 Value Object의 구분 Customer - Entity Cargo - Entity Handling Event와 Carrier Movement - Entity Location - 식별자로 작성 Delivery History - Entity Delivery Specification - Value Object Role/시간/날짜 - Value Object
  • 배송 도메인의 연관관계 설계연관 설정은 모델에 대한더 깊이 있는 통찰력을 제공한다.양방향 연관은 문제가 된다.
  • 연관관계 설정 Customer는 대체로 여러 객체와 연동되는 역할을 가짐. Customer에서 Cargo로 연 관되면, Customers 모두 반 복적으로 연관됨(???) 따라서, Cargo 에서 Customer로 연관시킨다. Customer를 이용하여 Cargo를 찾는 경우 Repository 방식을 적용함.
  • 연관관계 설정 배송에 대한 정보를 추적한다면, Carrier Movement 에서 Handling Event 로 연관되어야 하지만,(???) 화물을 추적해야 하므로, HE에서 CM로 연관을 만든다. (???)
  • 연관관계 설정 순환 참조는 필요할때도 있고 사용도 되지만, 유지보수를 어렵게 만듦. 동일한 정보를 2곳의 객체에 보관하지 않도록 구현. 자바 컬렉션등 단순한 수준에서 구현하거나, 데이터베이스로 구현가능. (성능과 유지보수의 trade-offs)
  • AGGREGATE 의 경계 Customer, Location, Carrier Movement 는 AGGREGATE 루트. DH, DS, HE는 Cargo에 종속되므로 Cargo AGGREGATE에 포함 시킴.
  • REPOSITORY 의 선정 Entity만 Repository를 가짐. 예약 App은 Customer, Location 을 사용하므로 각각의 Repo 필요. 추적 질의 ALA 은 Cargo, CM을 예약 APP 사용하므로 각각의 Repo 필요.사건 기록 APP
  • 시나리오 연습예제 어플리케이션 기능 : 화물의 목적지 변경DS은 Value Object이므로새로운 DS를 생성하여 교체함.
  • 시나리오 연습예제 어플리케이션 기능 : 반복 업무기존 Cargo 정보를 계속 사용할 경우,REPO에서 기존 Cargo 정보를 찾고,Prototype Pattern을 이용하여새 Cargo를 생성하도록 함. Delivery History는 새로 생성함. Customer Roles 은 동일하게 사용하는데, Customer는 복사 하지 않아야 함. Tracking ID 는 새로 생성해야 함.
  • 객체 생성Cargo에 대한 FACTORY와 생성자
  • 객체 생성Handling Event 추가 HE 는 Entity이므로 모든 속성이 생성자에 전달. 각 이벤트 타입에 대한 Factory Method를 추가.
  • 리팩터링할 시간 : Cargo AGGREGATE의설계 대안 HE 추가할 때, Cargo 를 통해 DH가 갱신. 여러 사용자가 참여하 는 경우 트랜잭션 처리 가 필요. Collection보다 데이터베이스를 이용.
  • 배송 모델의 모듈화 3개의 사용되는 형태로 (Entities, Values, Services) 구분하는 경우, 응집도가 떨어지고, 모듈간 높은 결합도.
  • 도메인에 근거한 모듈 이 모듈 설계는 팀내 사용언어(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 customers agreement.
  • 새로운 기능 도입: 할당량 검사예약 시스템에서 예약 수락 여부를설정할 수 있도록 기존 시스템과 통합.Cargo Repository와 Sales ManagementSystem 에 질의후 수락여부를 결정.
  • 두 시스템의 연계SMS은 기존 사용 시스템이고,현재 시스템에 추가하려면,MODEL-DRIVEN DESIGN, UBIQUITOUSLANGUAGE에 혼란.현재 시스템과 SMS 사이의 중간 클래스를 만들고,필요한 기능만 노출하여 도메인관점에서 재추상화.
  • 모델 강화 : 업무 분야 나누기 Enterprise Segment 라는 부가적인 Value Object로 추가. Allocation Checker는 ES와 SMS간 번역을 수행.
  • 성능 최적화Allocation Checker의 통신 부하 발생.캐싱을 사용해서 부하를 낮춤.설계 복잡, 캐시에 최신 정보 유지등 어려움.성능이 중요한 경우의 설계 목표.