Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications

7,278 views

Published on

Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,278
On SlideShare
0
From Embeds
0
Number of Embeds
2,524
Actions
Shares
0
Downloads
39
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

Software Design Trilogy Part III - Domain Driven Design for Ruby on Rails Applications

  1. 1. THE 80’S – RESPONSIBILITY DRIVEN DESIGN
  2. 2. THE 90’S – DESIGN PATTERNS
  3. 3. THE 2000’S – DOMAIN DRIVEN DESIGN
  4. 4. WHAT WILL BE COVERED•  Business Domain Modeling•  The Ubiquitous Language•  Model Driven Design•  Example Business Domain•  Demonstrative Rails Application
  5. 5. WHAT WON’T BE COVERED•  Refactoring Toward Deeper Insight•  Supple Design•  Large Scale Structure•  Bounded Contexts•  Distillation
  6. 6. 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
  7. 7. EXAMPLE WEBSITE© Old Town School of Folk Music
  8. 8. BUSINESS DOMAIN MODELING•  Knowledge Crunching•  Continuous Learning•  Deeper Models
  9. 9. 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?
  10. 10. 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
  11. 11. THE UBIQUITOUS LANGUAGE•  Model Out Loud•  One Team, One Language•  Documents and Diagrams•  Executable Bedrock•  Explanatory Models
  12. 12. MODEL OUT LOUD•  Students register in a class with an instructor•  Students attend events•  Customers buy music products•  Instructors teach classes•  Locations offer classes
  13. 13. ONE TEAM, ONE LANGUAGE•  Course vs Class•  Student vs Customer•  Teacher vs Instructor•  Event vs Concert•  Location vs Branch
  14. 14. DOCUMENTS•  Top level goals•  Top level requirements•  Top level use cases
  15. 15. DIAGRAMS Product Class Series Customer Class Session Location Event Instructor Performer
  16. 16. EXECUTABLE BEDROCK ANDEXPLANATORY MODELS•  Domain knowledge is apparent in code•  Method names describe behavior•  Class names map to actual business models
  17. 17. MODEL DRIVEN DESIGN•  Object Oriented Paradigm and Mixing Paradigms•  Layered Architecture•  Associations•  Entities•  Value Objects
  18. 18. MODEL DRIVEN DESIGN•  Services•  Modules•  Aggregates•  Factories•  Repositories
  19. 19. OBJECT ORIENTED PARADIGMAND MIXING PARADIGMS•  Objects can generally embody any domain•  Certain domains can benefit from mixing paradigms:•  Functional•  Logic•  Rule Engine
  20. 20. LAYERED ARCHITECTURE
  21. 21. ASSOCIATIONS•  Unidirectional•  Emphasizes natural bias for operation and domain logic•  Communicates association better•  Bidirectional•  Multiple entry points for operation
  22. 22. ASSOCIATIONS•  Buying•  Enrollment•  Performing•  Location•  Timing
  23. 23. 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
  24. 24. ENTITIES•  Examples:•  Customer•  Instructor•  Class
  25. 25. 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
  26. 26. 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
  27. 27. AGGREGATES•  Examples:•  ClassSeries aggregates Classes•  Customer aggregates Address•  Location aggregates Address
  28. 28. FACTORIES•  Handle creation of complex aggregate roots•  In Rails, typically handled by ActiveRecord•  When outgrowing ActiveRecord, split into a separete Ruby stateless class
  29. 29. FACTORIES•  Examples:•  ClassFactory handles creation of class with: •  Session association •  ClassCategory association •  Instructor association
  30. 30. 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
  31. 31. REPOSITORIES•  Examples: •  StudentRepository •  InstructorRepository •  SessionRepository
  32. 32. 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
  33. 33. SERVICES•  Examples:•  ClassEnrollmentService•  MusicStoreService•  EventTicketingService
  34. 34. MODULES•  Package cohesive units of business behavior•  Cut across software layers•  In Rails, handled with Modules and Rails Engines•  Examples:•  MusicStore•  ClassesEnrollment•  EventTicketing
  35. 35. RUBY ON RAILS APPLICATION
  36. 36. RUBY ON RAILS APPLICATION
  37. 37. RUBY ON RAILS APPLICATION
  38. 38. RUBY ON RAILS APPLICATION
  39. 39. RUBY ON RAILS APPLICATION
  40. 40. RUBY ON RAILS APPLICATION
  41. 41. WHAT WAS COVERED•  Business Domain Modeling•  The Ubiquitous Language•  Model Driven Design•  Example Business Domain•  Demonstrative Rails Application
  42. 42. QUESTIONS ???
  43. 43. 2010’S - ???
  44. 44. REFERENCES•  Domain-Driven Design by Eric Evans
  45. 45. CONTACT INFO•  Andy Maleh / Software Engineer / Groupon•  Blog: http://andymaleh.blogspot.com•  Twitter: @AndyMaleh

×