Harsh J egade d esa s n a ’ n s CLASSROOM DOMAIN-DRIVEN DESIGN BITS Pilani Off-Campus Work-Integrated Learning Programmes
AGENDA Why Domain-Driven Design? Core Patterns
ERIC EVANS SPEAKS Eric Evans, the author of Domain-Driven Design, has been programming and designing systems for 25 years He asserts that for most software projects, the primary focus should be on the domain and domain logi g c “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
“The goal of domain-driven design is to create better software by focusing on a model of the do d ma m in i n ra r t a h t e h r r t h t a h n n th t e h te t chn h o n lo l gy. y ” .
DDD LEADS TO MODEL-DRIVEN DESIGN Domain-Driven Design leads to Model-Driven Design since developers capture their knowledge of a domain in models In particular A A m ode d l- l d - r d iv i en d e d si s g i n is i s so s ft f w t a w r a e st s r t uctu t red d ar a ound d a set o domain concepts E.g.: A model-driven design for a UI framework is one in which UI concepts, such as windows and menus Teams who embrace model-driven design are aware that a change to the code IS a change to the model (and vice versa)
MODEL-DRIVEN DESIGN BENEFITS DDD The model and its implementation shape each other The link between model and code makes the model relevant and ensures that the work spent on analysis is not wasted The model creates a language used by all team members r The language spreads domain knowledge throughout a team It allows developers to speak to domain experts (e.g. users) without translation The model is distilled knowledge Analysis is hard; we need to capture the information we get from it The model is the team’s agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest
TACKLING COMPLEXITY The heart of software is its ability to solve domain-related problems for its users Software functionality either solves a domain-related problem or performs a domain-related task All other features support these two goals Whe h n n a d oma m in n i s s c o c mp m lex, , i t b eco c me m s s d ifficu c l u t l t o accomplish this To be successful, developers must steep themselves in the domain Problem: 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!
CRUNCHING KNOWLEDGE Domain modeling requires processing (crunching) knowledge In the same way that financial analysts crunch numbers While speaking with domain experts, a domain modeler will try one organizing idea (set of concepts) after another create models, try them out, reject some, transform others Success is achieved when the modeler has created a set of abstract concepts that makes sense of all the details provided by the domain experts Domain experts are a critical part of the process Without them, developers tend to create models with concepts that seem naive and shallow to domain experts
INGREDIENTS OF EFFECTIVE MODELING Bind the model and the implementation As a model is developed, create rapid prototypes that test the domain These prototypes contain primarily domain concepts no UI, no persistence, no infrastructure Develop a knowledge-rich model The objects of your model should have behavior and may follow rules The model should not be just a data schema (think class diagram) but should express behavior, constraints, etc. that help solve domain related problems
KNOWLEDGE-RICH DESIGN Models capture more information than just the “classes” of a domain it goes beyond the “find the nouns and verbs” heuristic of some object-oriented models In particular, models capture behavior, business activities, and business rules (policies, constraints, etc.)
EXAMPLE: MODELING BUSINESS RULES Th T e h a ss s o s ci c ation n m i m ght h l ook l ike t hi h s: s
EXAMPLE: OVER BOOKING CARGO? A standard practice in the shipping industry is to accept more cargo than a particular ship can carry on voyage This is know as “overbooking” and is used because th t ere a r a e ty t pi p c i al a l l y l a l a w l a w y a s s la l s a t s - t m - in i ute t c an a cell l a l t a i t o i ns One way of specifying the overbooking policy is via a percentage of the ship’s total capacity ~ 10%
EXAMPLE: HIDDEN KNOWLEDGE PROBLEM Overbooking policy is not reflected in our model The policy has been recorded in a requirements document and hidden away inside one method in our application Domai a n- n Driven v
en D esign g n r ecommend en s m ak a ing n g t ha h t a knowledge a part of the model: change the model, change the code (and vice versa)
EXAMPLE: CONTINUED, Our code would now look like this: and the OverBookingPolicy class would have a method:
PROBLEM It is not practical for software developers to become domain experts, or for domain experts to become software developers. Bot B h h p ar a ties c an a n ea
s ea ily y b ec b ome c e onf on us u ed b y b y the h plethora of undefined terminology and acronyms. Solution: Ubiquitous Language.
UBIQUITOUS LANGUAGE “A language structured around the domain model and used by all team member b s t o conn on ec n t a l a l t he h ac a tivi v ties of the team with the software.”
AGENDA Why Domain-Driven Design? Core Patterns
PROBLEM Domain-Driven Design is overkill. Very little domain logic. Mostly data entry / retrieval. Short deadline. Pr P ototyp y e or e a
a “one on of e f.” Low-level of modeling skill. Solution: Smart UI
SMART UI Put the business logic in the user interface. Create a separate user interface for every application function. Store a e l a l d at a a a i n n a
a sha h r a ed r elat a iona on l a d at a ab a a b s a e. Program in 4GL languages and use rapid prototyping tools; Java/C# is overkill.
PROBLEM Lots and lots of complicated domain logic. Long-lived project lifetime. Ambitious goals. High g - h level ev of m odeling n g s kill. Solution: (Domain) Model-Driven Design.
MODEL-DRIVEN DESIGN Uses a single model for both analysis (to understand the domain) and design (to implement the software). Requires an iterative development process and cont on inu n ou u s ou r efac a toring n . g Developers are also modelers. This is hard.
ASIDE: THE MODEL DEBATE What is the relationship between the domain model and the source code? “Ti T gh g t h ly y r elat a ing n g t he h c e ode t e o an a n u n u d n erlyi y ng n g m odel gives the code meaning and makes the model relevant.”
PROBLEM There is too much crap in my domain logic. I wish I could pull all of this crap out so that the model is easier to see and change. Solut u ion: on L a L y a er y ed Ar A chi h tectur u e Crap is a scientific term.
USER INTERFACE LAYER Presents information to the user and interprets the user's commands.
APPLICATION LAYER Defines the application services: what the software actually does for the user. Orchestrates the domain objects to implement these application services. Has a s tat a e reflecting n g t he h p e rogr og ess of a
a s ervi v ce c e al a l in execution. This layer is kept thin.
DOMAIN LAYER Represents concepts of the business, information about the business situation, and business rules. Maintains state reflecting the business situation. Th T i h s l ay a er y i s t he h h e ea h r ea t of b u b s u ines n s s oftwar a e.
INFRASTRUCTURE LAYER Provides generic technical capabilities that support the higher layers. Message sending Persi s s i t s e t nce Rendering UI widgets Etc. This layer could be a library or a framework.
CORE OBJECTS Entities Value Objects Services
ENTITIES “Objects which are not defined by their attributes, but rather by a thread of continuity and identity, which remains the h s e am a e thr h oug ou h g ou h t ou t he h l e ife of e t he h software and even beyond.”
VALUE OBJECTS “Immutable objects that have no conceptual identity and whose only pur u pose i e s t o d o escribe b s e ome a e t a tribu b t u e of another object.”
SERVICES “Objects that have no state and whose only purpose is to represent an operation on on t he h d e omai a n n i tself.”
PROBLEM The domain model is too big to understand. Solution: Module.
MODULE “A method of organizing related concepts and tasks in order to reduce complexity.”
DOMAIN OBJECT LIFE CYCLE
PROBLEM The object graph is biconnected. Every object has at least two references to other objects. Hard to enforce invariants. Har a d t o implement en d at a ab a a b s a e tran a s n ac a tions on without touching every object in the system. Solution: Aggregate.
AGGREGATE “A cluster of associated objects that are treated as a unit with regard to data changes.” All external access to the cluster is t hr h oug ou h g h a
a sing n l g e r e oot E n E t n ity. y The root Entity enforces invariants among the other objects.
PROBLEM Is the root Entity responsible for creating the Aggregate? Observation: Creation code is different than run- time b e eh b a eh v a i v or c ode. Solution: Factory.
FACTORY “Encapsulates the knowledge necessary for complex object creation.” Rel R eva ev n a t n p at a terns n : Factory Method Abstract Factory Builder
PROBLEM How do you find an Aggregate? Navigate a network of object references. Increases coupling. Pollutes the domain objects with extra references. Pull l l d a d t a a t a fr f om t h t e d a d t a a t b a a b s a e s . Should SQL go inside the domain objects? May violate data hiding principles. Solution: Repository.
REPOSITORY “Encapsulates database storage, retrieval, and search behavior which emulates a collection of objects.” Looks like java.util.Collection. Acts like a relational database.