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 BE COVERED
• Business Domain Modeling
• The Ubiquitous Language
• Model Driven Design
• Example Business Domain
• Demonstrative Rails Application

6. WHAT WON’T BE COVERED
• 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
© Old Town School of Folk Music

9. BUSINESS DOMAIN MODELING
• Knowledge Crunching
• Continuous Learning
• Deeper Models

10. 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?

11. 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

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, ONE LANGUAGE
• Course vs Class
• Student vs Customer
• Teacher vs Instructor
• Event vs Concert
• Location vs Branch

15. DOCUMENTS
• Top level goals
• Top level requirements
• Top level use cases

16. DIAGRAMS Product
Class Series
Customer
Class
Session
Location
Event
Instructor
Performer

17. EXECUTABLE BEDROCK AND
EXPLANATORY MODELS
• 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
AND MIXING PARADIGMS
• Objects can generally embody any domain
• Certain domains can benefit from mixing paradigms:
• Functional
• Logic
• Rule Engine

21. LAYERED ARCHITECTURE

22. ASSOCIATIONS
• Unidirectional
• Emphasizes natural 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 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

25. ENTITIES
• Examples:
• Customer
• Instructor
• Class

26. 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

27. 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

28. AGGREGATES
• Examples:
• ClassSeries aggregates Classes
• Customer aggregates Address
• Location aggregates Address

29. FACTORIES
• Handle creation of complex aggregate roots
• In Rails, typically handled by ActiveRecord
• When outgrowing ActiveRecord, split into a separete
Ruby stateless class

30. FACTORIES
• Examples:
• ClassFactory handles creation of class with:
• Session association
• ClassCategory association
• Instructor association

31. 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

32. REPOSITORIES
• Examples:
• StudentRepository
• InstructorRepository
• SessionRepository

33. 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

34. SERVICES
• Examples:
• ClassEnrollmentService
• MusicStoreService
• EventTicketingService

35. MODULES
• Package cohesive units of business behavior
• Cut across software layers
• In Rails, handled with Modules and Rails Engines
• Examples:
• MusicStore
• ClassesEnrollment
• EventTicketing

36. RUBY ON RAILS APPLICATION

37. RUBY ON RAILS APPLICATION

38. RUBY ON RAILS APPLICATION

39. RUBY ON RAILS APPLICATION

40. RUBY ON RAILS APPLICATION

41. RUBY ON RAILS APPLICATION

42. WHAT WAS COVERED
• Business Domain Modeling
• The Ubiquitous Language
• Model Driven Design
• Example Business Domain
• Demonstrative Rails Application

43. QUESTIONS
???

44. 2010’S - ???

45. REFERENCES
• Domain-Driven Design by Eric Evans

46. CONTACT INFO
• Andy Maleh / Software Engineer / Groupon
• Blog: http://andymaleh.blogspot.com
• Twitter: @AndyMaleh