Lecture 23: Domain-Driven Design (Part 1)Kenneth M. AndersonObject-Oriented Analysis and DesignCSCI 6448 - Spring Semester, 20051April 5, 2005 © University of Colorado, Boulder, 20052Goals for this lectureIntroduce the main concepts of Domain-Driven DesignModel-Driven DesignUbiquitous LanguagePresent examples that illustrate these conceptsGoals for the Domain-Driven Design LecturesCover chapters 1-7 and parts of chapter 10 in 4 lectures!April 5, 2005 © University of Colorado, Boulder, 2005Domain-Driven DesignEric Evans, the author of Domain-Driven Design, has been programming and designing systems for 25 yearsHe asserts that for most software projects, the primary focus should be on the domain and domain logic“Domain-driven design flows from the premise that the heart of software development is knowledge of the subject matter and finding useful ways of understanding that subject matter. The complexity that we should be tackling is the complexity of the domain itself -- not the technical architecture, not the user interface, not even specific features. This means designing everything around our understanding and conception of the most essential concepts of the business and justifying any other development by how it supports that core.”From <http://domaindrivendesign.org/articles/blog/evans_eric_ddd_and_mdd.html>3April 5, 2005 © University of Colorado, Boulder, 2005Model-Driven DesignDomain-Driven Design leads to Model-Driven Design since developers capture their knowledge of a domain in modelsIn particularA model-driven design is software structured around a set o domain concepts A model-driven design for a UI framework is one in which UI concepts, such as windows and menus, correspond to software constructsModel-driven design embeds a domain model into the very fabric of a software system.This creates a feedback loop between learning about a domain and implementing a system that addresses a problem in that domainTeams who embrace model-driven design are aware that a change to the code IS a change to the model (and vice versa)4April 5, 2005 © University of Colorado, Boulder, 2005Model Benefits in DDDThe model and its implementation shape each otherThe link between model and code makes the model relevant and ensures that the work spent on analysis is not wastedIndeed, the results of your analysis are present in the developed system!The model creates a language used by all team membersThe language spreads domain knowledge throughout a teamIt 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 get from itThe model is the team’s agreed-upon way of structuring domain knowledge and and distinguishing the elements of most interest5April 5, 2005 © University of Colorado, Boulder, 2005Tackling ComplexityThe heart of software is its ability to solve domain-related problems for its usersSoftware functionality either solves a domain-related problem or performs a domain-related taskAll other features support these two goalsWhen a domain is complex, it becomes difficult to accomplish thisTo 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 scienceDevelopers enjoy quantifiable problems that exercise their technical skills!Evans asserts that domain complexity has to be tackled head-on by developers or they risk irrelevance!6April 5, 2005 © University of Colorado, Boulder, 2005Crunching KnowledgeDomain modeling requires processing (crunching) knowledgeIn the same way that financial analysts crunch numbers to, e.g., understand the quarterly performance of a corporationWhile speaking with domain experts, a domain modeler willtry one organizing idea (set of concepts) after anothercreate models, try them out, reject some, transform othersSuccess is achieved when the modeler has created a set of abstract concepts that makes sense of all the details provided by the domain expertsDomain experts are a critical part of the processWithout them, developers tend to create models with concepts that seem naive and shallow to domain experts7April 5, 2005 © University of Colorado, Boulder, 2005Ingredients of Effective ModelingBind the model and the implementationAs a model is developed, create rapid prototypes that test the domainThese prototypes contain primarily domain conceptsno UI, no persistence, no infrastructureChapter 3 begins with a story of what happens when you don’t do this!Cultivate a language based on the modelDomain experts teach you their concepts and vocabularyYou teach them the basics of class diagrams and sequence diagrams (via the use of lots of examples)Eventually either side “can take terms straight out of the model, organize them into sentences consistent with the structure of the model, and be unambiguously understood without translation”8April 5, 2005 © University of Colorado, Boulder, 2005Ingredients of Effective Modeling, continuedDevelop a knowledge-rich modelThe objects of your model should have behavior and may follow rulesThe model should not be just a data schema (think class diagram) but should express behavior, constraints, etc. that help solve domain-related problemsDistill the modelIt will be easy to add concepts to a model but more important is learning to remove concepts that are no longer usefulBe willing to brainstorm and experiementTry out variations of the model with rapid prototypes; think of the model as a laboratory that can enable domain-related experimentsUse the results of those experiments to evolve the model9April 5, 2005 © University of Colorado, Boulder, 2005Example: PCB DesignChapter 1 contains a brief example of domain-driven design when the author was working with a team of printed-circuit board designersEvans knew nothing about electronic hardwareInitial conversations with the designers were difficultEvans was not an electrical engineer and didn’t understand the designers concepts or skillsThe designers were not software developers and could not explain the functionality they needed very wellThe first breakthrough came with Evans noticing that the concept of a “Net” kept appearing in the reports that the designers wanted from the software systemA net on a PCB is a wire conductor that connects a set of components and can carry an electric signal to each component its
View Full Document
Unlocking...