Downloaded 44 times
Uploaded byAndy Maleh
Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications
The document discusses domain-driven design approaches from the 1980s to present. It covers business domain modeling, the ubiquitous language, and model-driven design principles. An example domain of a music school is used, along with a Ruby on Rails application demonstration. Key concepts explained include entities, value objects, aggregates, factories, repositories, and services in the context of domain-driven design.
More Related Content
Similar to Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications
Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications
- 2. THE 80’S –RESPONSIBILITY DRIVEN DESIGN
- 3. THE 90’S –DESIGN PATTERNS
- 4. THE 2000’S –DOMAIN DRIVEN DESIGN
- 5. WHAT WILL BECOVERED • Business Domain Modeling • The Ubiquitous Language • Model Driven Design • Example Business Domain • Demonstrative Rails Application
- 6. WHAT WON’T BECOVERED • Refactoring Toward Deeper Insight • Supple Design • Large Scale Structure • Bounded Contexts • Distillation
- 7. 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
- 8. EXAMPLE WEBSITE © OldTown School of Folk Music
- 9. BUSINESS DOMAIN MODELING • Knowledge Crunching • Continuous Learning • Deeper Models
- 10. KNOWLEDGE CRUNCHING • Whattypes 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?
- 11. CONTINUOUS LEARNING ANDDEEPER MODELS • Instructors perform regularly at events • Instructors provide series of classes • Certain events recur regularly • Music store offers location pick up service
- 12. THE UBIQUITOUS LANGUAGE • Model Out Loud • One Team, One Language • Documents and Diagrams • Executable Bedrock • Explanatory Models
- 13. MODEL OUT LOUD • Students register in a class with an instructor • Students attend events • Customers buy music products • Instructors teach classes • Locations offer classes
- 14. ONE TEAM, ONELANGUAGE • Course vs Class • Student vs Customer • Teacher vs Instructor • Event vs Concert • Location vs Branch
- 15. DOCUMENTS • Top levelgoals • Top level requirements • Top level use cases
- 16. DIAGRAMS Product Class Series Customer Class Session Location Event Instructor Performer
- 17. EXECUTABLE BEDROCK AND EXPLANATORYMODELS • Domain knowledge is apparent in code • Method names describe behavior • Class names map to actual business models
- 18. MODEL DRIVEN DESIGN • Object Oriented Paradigm and Mixing Paradigms • Layered Architecture • Associations • Entities • Value Objects
- 19. MODEL DRIVEN DESIGN • Services • Modules • Aggregates • Factories • Repositories
- 20. OBJECT ORIENTED PARADIGM ANDMIXING PARADIGMS • Objects can generally embody any domain • Certain domains can benefit from mixing paradigms: • Functional • Logic • Rule Engine
- 21.
- 22. ASSOCIATIONS • Unidirectional • Emphasizesnatural bias for operation and domain logic • Communicates association better • Bidirectional • Multiple entry points for operation
- 23. ASSOCIATIONS • Buying • Enrollment • Performing • Location • Timing
- 24. ENTITIES • Have anidentity independent of attributes • Mutable • Have a life cycle • In Rails, typically handled with ActiveRecord • When outgrowing ActiveRecord split into a separate Ruby stateful class
- 25. ENTITIES • Examples: • Customer • Instructor • Class
- 26. VALUE OBJECTS • Identifiedby their attribute values • Immutable and unique • In Rails, typically handled by pure Ruby objects • Examples: • City • State • Class Name • Session Date Range
- 27. AGGREGATES • Aggregate rootsare 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
- 28. AGGREGATES • Examples: • ClassSeriesaggregates Classes • Customer aggregates Address • Location aggregates Address
- 29. FACTORIES • Handle creationof complex aggregate roots • In Rails, typically handled by ActiveRecord • When outgrowing ActiveRecord, split into a separete Ruby stateless class
- 30. FACTORIES • Examples: • ClassFactoryhandles creation of class with: • Session association • ClassCategory association • Instructor association
- 31. REPOSITORIES • Handle storageand 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
- 32. REPOSITORIES • Examples: • StudentRepository • InstructorRepository • SessionRepository
- 33. SERVICES • Model statelessbusiness 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
- 34. SERVICES • Examples: • ClassEnrollmentService • MusicStoreService • EventTicketingService
- 35. MODULES • Package cohesiveunits of business behavior • Cut across software layers • In Rails, handled with Modules and Rails Engines • Examples: • MusicStore • ClassesEnrollment • EventTicketing
- 36. RUBY ON RAILSAPPLICATION
- 37. RUBY ON RAILSAPPLICATION
- 38. RUBY ON RAILSAPPLICATION
- 39. RUBY ON RAILSAPPLICATION
- 40. RUBY ON RAILSAPPLICATION
- 41. RUBY ON RAILSAPPLICATION
- 42. WHAT WAS COVERED • Business Domain Modeling • The Ubiquitous Language • Model Driven Design • Example Business Domain • Demonstrative Rails Application
- 43. QUESTIONS ???
- 44.
- 45. REFERENCES • Domain-Driven Designby Eric Evans
- 46. CONTACT INFO • AndyMaleh / Software Engineer / Groupon • Blog: http://andymaleh.blogspot.com • Twitter: @AndyMaleh