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