Post on 10-May-2015
description
transcript
THE 80’S – RESPONSIBILITY DRIVEN DESIGN
THE 90’S – DESIGN PATTERNS
THE 2000’S – DOMAIN DRIVEN DESIGN
WHAT WILL BE COVERED
• Business Domain Modeling • The Ubiquitous Language • Model Driven Design • Example Business Domain • Demonstrative Rails Application
WHAT WON’T BE COVERED
• Refactoring Toward Deeper Insight • Supple Design • Large Scale Structure • Bounded Contexts • Distillation
MUSIC SCHOOL BUSINESS
• Offers classes for playing music, singing, and dancing • Has a music instrument store that sells products • Hosts music events with famous musicians • Available in multiple locations
EXAMPLE WEBSITE © Old Town School of Folk Music
BUSINESS DOMAIN MODELING
• Knowledge Crunching • Continuous Learning • Deeper Models
KNOWLEDGE CRUNCHING
• What types of classes do you offer? • Do you offer the same classes in all locations? • Do you sell anything other than music instruments? • Are events paid for or free? • How many classes does each instructor teach? • How many lessons is a class? • Do classes vary from session to session?
CONTINUOUS LEARNING AND DEEPER MODELS
• Instructors perform regularly at events • Instructors provide series of classes • Certain events recur regularly • Music store offers location pick up service
THE UBIQUITOUS LANGUAGE
• Model Out Loud • One Team, One Language • Documents and Diagrams • Executable Bedrock • Explanatory Models
MODEL OUT LOUD
• Students register in a class with an instructor • Students attend events • Customers buy music products • Instructors teach classes • Locations offer classes
ONE TEAM, ONE LANGUAGE
• Course vs Class • Student vs Customer • Teacher vs Instructor • Event vs Concert • Location vs Branch
DOCUMENTS
• Top level goals • Top level requirements • Top level use cases
DIAGRAMS
Customer Class
Location
Instructor
Event
Performer
Session
Class Series
Product
EXECUTABLE BEDROCK AND EXPLANATORY MODELS • Domain knowledge is apparent in code • Method names describe behavior • Class names map to actual business models
MODEL DRIVEN DESIGN
• Object Oriented Paradigm and Mixing Paradigms • Layered Architecture • Associations • Entities • Value Objects
MODEL DRIVEN DESIGN
• Services • Modules • Aggregates • Factories • Repositories
OBJECT ORIENTED PARADIGM AND MIXING PARADIGMS • Objects can generally embody any domain • Certain domains can benefit from mixing paradigms: • Functional • Logic • Rule Engine
LAYERED ARCHITECTURE
ASSOCIATIONS
• Unidirectional • Emphasizes natural bias for operation and domain logic • Communicates association better
• Bidirectional • Multiple entry points for operation
ASSOCIATIONS
• Buying • Enrollment • Performing • Location • Timing
ENTITIES
• Have an identity independent of attributes • Mutable • Have a life cycle • In Rails, typically handled with ActiveRecord • When outgrowing ActiveRecord split into a separate
Ruby stateful class
ENTITIES
• Examples: • Customer • Instructor • Class
VALUE OBJECTS
• Identified by their attribute values • Immutable and unique • In Rails, typically handled by pure Ruby objects • Examples: • City • State • Class Name • Session Date Range
AGGREGATES
• Aggregate roots are entities aggregating other entities • Manage the life cycle events of other entities • Non-aggregates are discouraged from being accessed
directly to simply reasoning about the domain code • In Rails, typically handled by ActiveRecord • When outgrowing ActiveRecord, split off into a stateful
Ruby class and handle life-cycle hooks in an observer
AGGREGATES
• Examples: • ClassSeries aggregates Classes • Customer aggregates Address • Location aggregates Address
FACTORIES
• Handle creation of complex aggregate roots • In Rails, typically handled by ActiveRecord • When outgrowing ActiveRecord, split into a separete
Ruby stateless class
FACTORIES
• Examples: • ClassFactory handles creation of class with: • Session association • ClassCategory association • Instructor association
REPOSITORIES
• Handle storage and retrieval of aggregate roots • Manage lifecycle events • In Rails, typically handled by ActiveRecord • When outgrowing ActiveRecord, split into a separate
stateless Ruby class that delegates work to ActiveRecord
REPOSITORIES
• Examples: • StudentRepository • InstructorRepository • SessionRepository
SERVICES
• Model stateless business processes without a lifecycle • Useful for operations that span multiple entities • Often represent use cases • In Rails, typically represented in controllers that mix
view concerns • When outgrowing Rails controllers, split into stateless
Ruby service objects
SERVICES
• Examples: • ClassEnrollmentService • MusicStoreService • EventTicketingService
MODULES
• Package cohesive units of business behavior • Cut across software layers • In Rails, handled with Modules and Rails Engines • Examples: • MusicStore • ClassesEnrollment • EventTicketing
RUBY ON RAILS APPLICATION
RUBY ON RAILS APPLICATION
RUBY ON RAILS APPLICATION
RUBY ON RAILS APPLICATION
RUBY ON RAILS APPLICATION
RUBY ON RAILS APPLICATION
WHAT WAS COVERED
• Business Domain Modeling • The Ubiquitous Language • Model Driven Design • Example Business Domain • Demonstrative Rails Application
QUESTIONS ???
2010’S - ???
REFERENCES
• Domain-Driven Design by Eric Evans
CONTACT INFO
• Andy Maleh / Software Engineer / Groupon • Blog: http://andymaleh.blogspot.com • Twitter: @AndyMaleh