Domain Driven Design

Download Domain Driven Design

Post on 10-May-2015




2 download

Embed Size (px)


<ul><li>1.Harsh Jegadeesans CLASSROOM DOMAIN-DRIVEN DESIGNBITS PilaniOff-Campus Work-Integrated Learning Programmes </li></ul> <p>2. AGENDAWhy Domain-Driven Design? Core Patterns 3. ERIC EVANS SPEAKSEric Evans, the author of Domain-Driven Design, hasbeen programming and designing systems for 25yearsHe asserts that for most software projects, theprimary focus should be on the domain and domainlogicDomain-driven design flows from the premise that the heart ofsoftware development is knowledge of the subject matter andfinding useful ways of understanding that subject matter. Thecomplexity that we should be tackling is the complexity of thedomain itself -- not the technical architecture, not the userinterface, not even specific features. This means designingeverything around our understanding and conception of the mostessential concepts of the business and justifying any otherdevelopment by how it supports that core. From 4. The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology. 5. DDD LEADS TO MODEL-DRIVEN DESIGNDomain-Driven Design leads to Model-DrivenDesign since developers capture their knowledgeof a domain in modelsIn particularA model-driven design is software structured arounda set o domain conceptsE.g.: A model-driven design for a UI framework isone in which UI concepts, such as windows andmenusTeams who embrace model-driven design are awarethat a change to the code IS a change to the model(and vice versa) 6. MODEL-DRIVEN DESIGN BENEFITS DDDThe model and its implementation shape each otherThe link between model and code makes the modelrelevant and ensures that the work spent on analysis is notwastedThe model creates a language used by all teammembersThe language spreads domain knowledge throughout ateamIt allows developers to speak to domain experts (e.g. users)without translationThe model is distilled knowledgeAnalysis is hard; we need to capture the information we getfrom itThe model is the teams agreed-upon way of structuringdomain knowledge and distinguishing the elements of mostinterest 7. TACKLING COMPLEXITYThe heart of software is its ability to solve domain-relatedproblemsfor its users Software functionality either solves a domain-related problem or performs a domain-related task All other features support these two goalsWhen a domain is complex, it becomes difficult toaccomplish this To be successful, developers must steep themselves in the domainProblem: Most developers are not interested in this! Domain work is messy and demands a lot of knowledge not necessarily related to computer science Developers enjoy quantifiable problems that exercise their technical skills! But, domain complexity has to be tackled head-on by developers or they risk irrelevance! 8. CRUNCHING KNOWLEDGEDomain modeling requires processing (crunching)knowledgeIn the same way that financial analysts crunch numbersWhile speaking with domain experts, a domainmodeler willtry one organizing idea (set of concepts) after anothercreate models, try them out, reject some, transform othersSuccess is achieved when the modeler has created aset of abstract concepts that makes sense of all thedetails provided by the domain expertsDomain experts are a critical part of the processWithout them, developers tend to create models withconcepts that seem naive and shallow to domain experts 9. INGREDIENTS OF EFFECTIVE MODELINGBind the model and the implementationAs a model is developed, create rapid prototypes thattest the domainThese prototypes contain primarily domain conceptsno UI, no persistence, no infrastructureDevelop a knowledge-rich modelThe objects of your model should have behavior andmay follow rulesThe model should not be just a data schema (thinkclass diagram) but should express behavior,constraints, etc. that help solve domain relatedproblems 10. KNOWLEDGE-RICH DESIGNModels capture more information than just theclasses of a domainit goes beyond the find the nouns and verbsheuristic of some object-oriented modelsIn particular, models capture behavior, businessactivities, and business rules (policies,constraints, etc.) 11. EXAMPLE: MODELING BUSINESS RULESThe association might look like this: 12. EXAMPLE: OVER BOOKING CARGO?A standard practice in the shipping industry is toaccept more cargo than a particular ship cancarry on voyageThis is know as overbooking and is used becausethere are typically always last-minute cancellationsOne way of specifying the overbooking policy is via apercentage of the ships total capacity ~ 10% 13. EXAMPLE: HIDDEN KNOWLEDGE PROBLEMOverbooking policy is not reflected in our modelThe policy has been recorded in a requirementsdocument and hidden away inside one method in ourapplicationDomain-Driven Design recommends making thatknowledge a part of the model: change the model,change the code (and vice versa) 14. EXAMPLE: CONTINUED,Our code would now look like this:and the OverBookingPolicy class would have a method: 15. PROBLEM It is not practical for software developers tobecome domain experts, or for domain experts tobecome software developers.Both parties can easily become confused by theplethora of undefined terminology and acronyms.Solution: Ubiquitous Language. 16. UBIQUITOUS LANGUAGE 17. UBIQUITOUS LANGUAGE A language structured around thedomain model and used by all teammembers to connect all the activitiesof the team with the software. 18. AGENDAWhy Domain-Driven Design? Core Patterns 19. PROBLEMDomain-Driven Design is overkill.Very little domain logic.Mostly data entry / retrieval.Short deadline.Prototype or a one off.Low-level of modeling skill.Solution: Smart UI 20. SMART UI Put the business logic in the user interface.Create a separate user interface for everyapplication function.Store all data in a shared relational database.Program in 4GL languages and use rapidprototyping tools; Java/C# is overkill. 21. PROBLEM Lots and lots of complicated domain logic.Long-lived project lifetime.Ambitious goals.High-level of modeling skill.Solution: (Domain) Model-Driven Design. 22. MODEL-DRIVEN DESIGN Uses a single model for both analysis (to understandthe domain) and design (to implement the software).Requires an iterative development process andcontinuous refactoring.Developers are also modelers. This is hard. 23. ASIDE: THE MODEL DEBATEWhat is the relationship between the domain model and the source code? Tightly relating the code to an underlying model gives the code meaning andmakes the model relevant. 24. PROBLEM There is too much crap in my domain logic.I wish I could pull all of this crap out so that themodel is easier to see and change.Solution: Layered ArchitectureCrap is a scientific term. 25. LAYERED ARCHITECTURE 26. USER INTERFACE LAYER Presents information to the user and interpretsthe user's commands. 27. APPLICATION LAYER Defines the application services: what thesoftware actually does for the user.Orchestrates the domain objects to implementthese application services.Has state reflecting the progress of a service callin execution.This layer is kept thin. 28. DOMAIN LAYER Represents concepts of the business, informationabout the business situation, and business rules.Maintains state reflecting the business situation.This layer is the heart of business software. 29. INFRASTRUCTURE LAYER Provides generic technical capabilities thatsupport the higher layers.Message sendingPersistenceRendering UI widgetsEtc.This layer could be a library or a framework. 30. CORE OBJECTS EntitiesValue ObjectsServices 31. ENTITIESObjects which are not defined by their attributes,but rather by a thread ofcontinuity and identity, which remainsthe same throughout the life of thesoftware and even beyond. 32. VALUE OBJECTS Immutable objects that have no conceptual identity and whose onlypurpose is to describe some attribute of another object. 33. SERVICES Objects that have no state and whose only purpose is to represent an operationon the domain itself. 34. PROBLEM The domain model is too big to understand.Solution: Module. 35. MODULE A method of organizing related concepts and tasks in order to reduce complexity. 36. DOMAIN OBJECT LIFE CYCLE 37. PROBLEMThe object graph is biconnected.Every object has at least two references to otherobjects.Hard to enforce invariants.Hard to implement database transactionswithout touching every object in the system.Solution: Aggregate. 38. AGGREGATE A cluster of associated objects that are treated as a unit with regard to data changes.All external access to the clusteris through a single root Entity.The root Entity enforces invariantsamong the other objects. 39. PROBLEM Is the root Entity responsible for creating theAggregate?Observation: Creation code is different than run-time behavior code.Solution: Factory. 40. FACTORY Encapsulates the knowledge necessary for complex object creation.Relevant patterns: Factory Method Abstract Factory Builder 41. PROBLEMHow do you find an Aggregate?Navigate a network of object references.Increases coupling.Pollutes the domain objects with extra references.Pull data from the database.Should SQL go inside the domain objects?May violate data hiding principles.Solution: Repository. 42. REPOSITORY Encapsulates database storage,retrieval, and search behavior whichemulates a collection of objects.Looks like java.util.Collection. Acts like a relational database. 43. THE END </p>