Lecture 26: Domain-Driven Design (Part 4)Kenneth M. AndersonObject-Oriented Analysis and DesignCSCI 4448/6448 - Spring Semester, 20051April 14, 2005 © University of Colorado, Boulder, 20052Goals for this lectureReview the extended example presented in chapter 7 of Domain-Driven DesignCargo Delivery ExampleApril 14, 2005 © University of Colorado, Boulder, 2005First Three LecturesThe last 3 lectures covered the pattern language of Domain Driven Design; Each core concept in the book is presented as a patternUbiquitous Language and Model Driven DesignLayered ArchitectureEntities, Value Objects, Services, ModulesAggregates, Factories, RepositoriesUsing these patterns, Evans claims, can improve the quality of software development life cycles; leading you to a place whereanalysis and design information are captured in codedomain complexities are partitioned into useful structuresthe life cycles of domain objects are managed efficiently3April 14, 2005 © University of Colorado, Boulder, 2005Chapter 7In chapter 7, Evans tries to bring the pattern language to bear on one example, to show how the parts work togetherThe domain: cargo trackingThe requirementsTrack key handling of customer cargoBook cargo in advanceSend invoices to customers automaticallyThe initial model (page 164)Customer, Cargo, Delivery History, Delivery SpecificationHandling Event, Carrier Movement, LocationIt would take a while to get to this point in the model’s development4April 14, 2005 © University of Colorado, Boulder, 2005Model BenefitsThis model provides several benefitsIt captures domain knowledgeMultiple Customers are involved with a Cargo, each playing some roleA series of Carrier Movements satisfying the Specification will fulfill the delivery goalThese statements can be constructed directly from observing the model (a feature related to the Ubiquitous Language pattern)Each element in the model has a clear meaningHandling Event is a discrete action taken with the CargoDelivery Specification defines a delivery goalThis keeps this concern out of the Cargo class; keeping cohesion high...5April 14, 2005 © University of Colorado, Boulder, 2005On to DesignThe requirements and the model are produced by analysisThe example starts with the transition to the design phaseWe begin by applying the Layered Architecture patternThe model is placed in the domain layerWe now identify classes that will be needed in the application layerApplication LayerThree functions needed to solve the requirements areRecording what happens to each cargo (Incident Logging Application)Handling requests to book cargo (Booking Application)Searching for the current or past status of a cargo (Tracking Query)These classes are coordinators that use the domain layer6April 14, 2005 © University of Colorado, Boulder, 2005Identifying Entities and ValuesAnother important issue is identifying what concepts in the domain have identity that must be tracked by our applicationAfter analysis all concepts except Delivery Specifications are identified as Entity objectsCustomers, Cargo, Handling Events, Carrier Movements, Location, etc.Most will have automatically generated ids; Handling Events are different because a domain expert reveals that each such event can be uniquely identified by combining a cargo’s id with its completion time and typeThe same Cargo cannot be loaded and unloaded at the same timeDelivery Specifications are Value Objects because they can be shared by two cargos going to the same placeEventually, we hope, the cargo’s Delivery History should end with an “unload” event at the Location indicated in the Delivery Specification7April 14, 2005 © University of Colorado, Boulder, 2005Designing AssociationsWe need to revisit the associations in the model to attempt to reduce the implementation complexity and to better match our requirements (see page 170)For instance, the association between Handling Events and Carrier Movements is bi-directional and has multiplicity in one directionIf we were tracking the inventory of ships, we would want to traverse from Carrier Movements to Handling Events; but, we are just tracking individual pieces of cargo; add directionality on that relationship to show we only need to implement one directionWe have one cycle in the modelCargo ! Delivery History ! Handling Event ! CargoCycles are tricky; need to balance complexity of implementation with performance; for instance, a database lookup on one of the associations can break the cycle but may impede performance if done frequently8April 14, 2005 © University of Colorado, Boulder, 2005Designing AggregatesNeed to examine model for aggregate boundariesCustomers, Locations, and Carrier Movements have their own identities and are (potentially) shared by many Cargosthey should each (possibly) be the root of their own Aggregatesthey may also just be Entities that do not have a complex internal structureCargo requires additional thought (page 171)Delivery History and Delivery Specifications are obvious elements of a Cargo aggregateHandling Event, however, is not because we previously identified the need to search for handling events in two separate instancesLooking for handling events related to a particular CargoLooking for handling events related to a particular Carrier MovementEven though we decided we didn’t need this particular query to meet our requirements; requirements can change!9April 14, 2005 © University of Colorado, Boulder, 2005Selecting RepositoriesThere are five Entity objects in the design, each a root of an aggregateWe need to decide which ones deserve repositoriesRecall that some objects we need to find via queries others we will “find” by traversing associationsTo do this, we return to our three application functionsThe booking application needs to look up Customers and LocationsIt creates CargosThe Incident Logging Application needs to look up Carrier Movements and CargosThe Tracking Query needs to look up Cargos (it gets to handling events by traversing associations)As such, we add four repositories (page 172)10April 14, 2005 © University of Colorado, Boulder, 2005Walking Through ScenariosWe must continually check our decisions by “walking through” scenarios (think “use cases”) to make sure we can meet our requirementsTwo ExamplesChanging a Cargo’s DestinationCreate a new Delivery Specification and update the Cargo objectRepeat Business (Cargos from repeat customers are often very similar)Use old Cargos as a template
View Full Document
Unlocking...