My domain is mine and I don't share it

What's business logic exactly? What's a domain model? Which truths hide behind "patterns" like fat model - skinny controller? How does the use of a framework like Rails influence how we build a domain model?

This talk will approach the problems that we have to face when we put a tool in the core of our system and we will discuss whether the price we pay for the rails is too high.

This talk was given on Madrid.rb users group.

Transcript

1. My Domain is Mine
   jacegu jacegu
   javieracero.com
   and I don’t share it !!
   

   View Slide

2. once upon a time...
   

   View Slide

3. there was a keynote
   

   View Slide

4. ARCHITECTURE
   the lost years
   Robert Martin / Uncle Bob
   

   View Slide

5. ARCHITECTURE
   “WEB”
   IS NOT AN
   

   View Slide

6. IS DELIVERED
   “WEB”
   IS HOW YOUR APP
   

   View Slide

7. ARCHITECTURE
   FRAMEWORKS
   IS NOT ABOUT
   

   View Slide

8. ARCHITECTURE
   DEFERRING
   IS ABOUT
   DECISIONS
   

   View Slide

9. FRAMEWORKS
   A DETAIL
   ARE JUST
   

   View Slide

10. RAILS
    IS A
    DETAIL
    

    View Slide

11. RAILS
    IS NOT
    YOUR APP
    

    View Slide

12. RAILS
    IS NOT
    A WAY
    

    View Slide

13. View Slide

14. View Slide

15. View Slide

16. wait a minute...
    

    View Slide

17. WTF
    DOES THAT
    EVEN MEAN
    ????????????????????????
    ????????????????????????
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    

    View Slide

18. let’s think it through
    

    View Slide

19. jacegu jacegu
    javieracero.com
    

    View Slide

20. View Slide

21. View Slide

22. View Slide

23. View Slide

24. PRESENTATION
    BUSINESS LOGIC
    DATA SOURCES
    1
    2
    3
    

    View Slide

25. ARE THESE 3 LAYERS YOUR APP?
    ARE THEY EQUALLY IMPORTANT?
    DO THEY OBEY THE SAME RULES?
    DO THEY CHANGE AT THE SAME PACE?
    

    View Slide

26. ARE THESE 3 LAYERS YOUR APP?
    ARE THEY EQUALLY IMPORTANT?
    DO THEY OBEY THE SAME RULES?
    DO THEY CHANGE AT THE SAME PACE?
    

    View Slide

27. ARE THESE 3 LAYERS YOUR APP?
    ARE THEY EQUALLY IMPORTANT?
    DO WE BUILD THEM THE SAME WAY?
    DO THEY CHANGE AT THE SAME PACE?
    

    View Slide

28. ARE THESE 3 LAYERS YOUR APP?
    ARE THEY EQUALLY IMPORTANT?
    DO WE BUILD THEM THE SAME WAY?
    DO THEY CHANGE AT THE SAME PACE?
    

    View Slide

29. HOW OFTEN DO
    BUSINESS
    RULES
    CHANGE
    

    View Slide

30. HOW OFTEN DO
    DOMAIN
    RULES
    CHANGE
    

    View Slide

31. HOW OFTEN DO
    NAMING
    RULES
    CHANGE
    

    View Slide

32. IT’S ALL ABOUT
    CHANGE
    

    View Slide

33. BUSINESS
    is a DIFFERENT
    LOGIC
    KIND OF BEAST
    

    View Slide

34. ????????????????????????
    ????????????????????????
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    what’s
    business logic
    

    View Slide

35. IKIPEDI
    W A
    

    View Slide

36. Business logic is a non-technical term
    used to describe the functional algorithms
    that handle information exchange
    between a database and a user interface
    - WIKIPEDIA
    

    View Slide

37. Business logic is a non-technical term
    used to describe the functional algorithms
    that handle information exchange
    between a database and a user interface
    - WIKIPEDIA
    

    View Slide

38. LET’S ASK @DHH
    

    View Slide

39. LET’S ASK @DHH
    http://37signals.com/svn/posts/3375-the-five-programming-books-that-meant-most-to-me
    

    View Slide

40. View Slide

41. View Slide

42. View Slide

43. Business logic is the work
    the application needs to do
    for the domain it’s working
    with
    - Martin Fowler
    - Patterns of Enterprise Application Architecture
    

    View Slide

44. CALCULATIONS
    VALIDATIONS
    CALLS TO OTHER SYSTEMS
    BUSINESS LOGIC
    

    View Slide

45. yep, sure, but...
    how does it look like
    ????????????????????????
    ????????????????????????
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    

    View Slide

46. MORE
    PEAA
    

    View Slide

47. TRANSACTION
    SCRIPT
    

    View Slide

48. TRANSACTIONS
    business logic as
    

    View Slide

49. PROCEDURES
    modeled as
    def new_purchase
    DB.insert(data)
    DB.commit;
    end
    

    View Slide

50. simple
    easy to understand
    works great with simple datasources
    makes transaction boundaries visible
    00
    {ADVANTAGES
    

    View Slide

51. DIS
    00
    {duplicated code procedural code
    duplicated code procedural code
    duplicated code procedural code
    duplicated code procedural code
    ADVANTAGES
    

    View Slide

52. duplicated code
    gets worse as the application grows
    time
    

    View Slide

53. TABLE
    MODULE
    

    View Slide

54. OPERATIONS
    business logic as
    TABLE ROWS
    on
    

    View Slide

55. OBJECTS
    modeled as
    class Product
    def purchase
    recordSet.save
    RECORD SETS
    &
    class RecordSet
    

    View Slide

56. helps overcoming the
    relational - o.o. mismatch
    avoids duplication better than a
    transaction script
    00
    {ADVANTAGES
    

    View Slide

57. 00
    {modeling limited by and tied to
    the data model
    mechanisms basic to oop like
    polymorphism are not available
    DISADVANTAGES
    

    View Slide

58. DOMAIN
    MODEL
    

    View Slide

59. A software model based specifically
    in the domain of the business you
    are working with.
    - Vaughn Vernon
    - Implementing Domain Driven Design
    

    View Slide

60. It’s usually built as an object model,
    where objects have both data and
    behaviour with accurate business
    meaning.
    - Vaughn Vernon
    - Implementing Domain Driven Design
    

    View Slide

61. OBJECT
    business logic as
    BEHAVIOUR
    

    View Slide

62. OBJECT GRAPHS
    modeled as
    Product
    Price
    Stock
    ProductService
    ProductRepository
    

    View Slide

63. The Object Oriented way of
    implementing business logic.
    - Martin Fowler
    - Patterns of Enterprise Application Architecture
    

    View Slide

64. - Martin Fowler
    - Patterns of Enterprise Application Architecture
    Using a Domain Model as opposed
    to a Transaction Script is the
    essence of the paradigm shift to
    Object Oriented programming.
    

    View Slide

65. The Object Oriented way of
    implementing business logic.
    ADVANTAGES
    

    View Slide

66. the hardest to comprehend
    data sources get more complex
    overhead for simple business logic
    DISADVANTAGES
    00
    {
    

    View Slide

67. which one
    should I use?
    ????????????????????????
    ????????????????????????
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    ?
    

    View Slide

68. effort to enhance
    complexity of the business logic
    domain model
    table module
    transaction script
    

    View Slide

69. 7.42
    effort to enhance
    complexity of the business logic
    domain model
    table module
    transaction script
    

    View Slide

70. dude... get to the point!
    

    View Slide

71. HOW DOES
    “BUSINESS LOGIC ON RAILS”
    LOOK LIKE
    

    View Slide

72. probably a
    “domain model”
    

    View Slide

73. PROGRAMMING
    IS HARD
    

    View Slide

74. DESIGN IS EVEN
    HARDER
    

    View Slide

75. IMPLEMENTING A
    DOMAIN MODEL
    IS NOT EASY
    

    View Slide

76. antipatterns
    

    View Slide

77. ANEMIC
    DOMAIN
    MODEL
    

    View Slide

78. OBJECTS HAVE
    NO BEHAVIOUR
    

    View Slide

79. BUSINESS LOGIC IS
    SOMEWHERE ELSE
    

    View Slide

80. IN CONTROLLERS
    IN SERVICES
    so-called
    

    View Slide

81. J2EE WAY?
    

    View Slide

82. J2EE WAY?
    transaction script
    

    View Slide

83. SKINNY CONTROLLER
    FAT MODEL
    http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
    

    View Slide

84. Controller
    Model
    

    View Slide

85. Controller
    Model
    THE
    PIPE
    REFACTOR
    

    View Slide

86. Controller
    Model
    http://joncairns.com/2013/04/fat-model-skinny-controller-is-a-load-of-rubbish/
    this won’t create
    a domain model
    

    View Slide

87. Controller
    Model
    http://joncairns.com/2013/04/fat-model-skinny-controller-is-a-load-of-rubbish/
    this is just turning
    a transaction script
    upside down
    

    View Slide

88. DESIGN PATTERN
    “PUSH IT DOWN”
    IS NOT A
    

    View Slide

89. Controller
    Model
    

    View Slide

90. Controller
    Model
    

    View Slide

91. Controller
    Model
    look!
    a god object
    

    View Slide

92. do not worry pal...
    rails has a way to tackle that!
    CONCERNS
    

    View Slide

93. View Slide

94. View Slide

95. View Slide

96. RUBY IS DYNAMIC
    IN NATURE
    

    View Slide

97. View Slide

98. SAME COMPLEXITY
    SAME L O C COUNT
    or even bigger! . . .
    http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm
    

    View Slide

99. CONCERNS
    ARE A TEXT EDITOR FEATURE
    

    View Slide

100. INHERITANCE
     MIXINS
     CONCERNS
     

     View Slide

101. MULTIPLE INHERITANCE
     MIXINS
     CONCERNS
     

     View Slide

102. INHERITANCE IS
     THE STRONGEST FORM
     OF COUPLING
     

     View Slide

103. http://www.midmarsh.co.uk/planetjava/tutorials/design/InheritanceConsideredHarmful.PDF
     CONSIDERED
     HARMFUL
     INHERITANCE
     

     View Slide

104. http://www.artima.com/weblogs/viewpost.jsp?thread=246341
     CONSIDERED
     HARMFUL
     MIXINS
     

     View Slide

105. TABLE DRIVEN
     DOMAIN MODEL
     

     View Slide

106. WHEN THE DOMAIN MODEL
     IS A DATA MODEL
     

     View Slide

107. :Payment
     EVERY DOMAIN OBJECT
     HAS A TABLE BEHIND IT
     :Product :Purchase
     

     View Slide

108. Another argument against ActiveRecord is the
     fact that it couples the object design to the
     database design.
     This makes difficult to refactor either design as
     the project goes forward.
     - Martin Fowler
     - Patterns of Enterprise Application Architecture
     

     View Slide

109. ACTIVE RECORD
     

     View Slide

110. ACTIVE RECORD
     GuILTY
     http://railsoopbook.com
     

     View Slide

111. View Slide

112. DATABASES
     A HARDWARE
     SOLVE
     PROBLEM
     

     View Slide

113. DATA SOURCES
     3
     databases
     belong in here
     

     View Slide

114. databases
     belong in here
     BUSINESS LOGIC
     2
     do not
     

     View Slide

115. CRUD
     OBSESSION
     the
     

     View Slide

116. Active Record is a good choice for business
     logic that is not too complex, such as creates,
     reads updates and deletes
     - Martin Fowler
     - Patterns of Enterprise Application Architecture
     

     View Slide

117. Creates
     Deletes
     Reads
     Updates
     

     View Slide

118. Database
     Database
     Database
     Database
     

     View Slide

119. }
     Creates
     Deletes
     Reads
     Updates
     are consequences
     of use cases
     not use casesthemselves
     

     View Slide

120. we are not digitalizing paper anymore
     

     View Slide

121. there is an app for that
     

     View Slide

122. DOMAIN MODEL
     CONNECTED
     

     View Slide

123. a. k. a.
     RAILS WAY’S
     DOMAIN MODEL
     THE
     

     View Slide

124. a. k. a.
     FRAMEWORK
     DOMAIN MODEL
     THE
     

     View Slide

125. a. k. a.
     CONNECTED DESIGN
     DOMAIN MODEL
     THE
     

     View Slide

126. a. k. a.
     ARCHITECTURELESS
     DOMAIN MODEL
     THE
     

     View Slide

127. a. k. a.
     RAILS IS YOUR APP
     DOMAIN MODEL
     THE
     

     View Slide

128. NO LAYERING
     

     View Slide

129. NO SEPARATION OF
     PRESENTATION
     BUSINESS LOGIC
     DATA SOURCES
     1
     2
     3
     

     View Slide

130. View Slide

131. STATE
     GL BAL
     

     View Slide

132. business logic
     context
     it’s running in
     <>
     

     View Slide

133. http://permalink.gmane.org/gmane.comp.programming.goos/1895
     An object whose design depends on its persistence
     mechanism: context dependent.
     Painful.
     - J. B. Rainsberger
     - On the GOOS Mailing List
     

     View Slide

134. http://michaelfeathers.typepad.com/michael_feathers_blog/2013/01/the-framework-superclass-anti-pattern.html
     When you inherit code from a framework, it is mixed
     with your logic. Often you are obliged to run that
     inherited code with the code that you really want to
     test, along with all of its dependencies, start up time...
     - Michael Feathers
     - On his blog on January 2013
     

     View Slide

135. http://michaelfeathers.typepad.com/michael_feathers_blog/2013/01/the-framework-superclass-anti-pattern.html
     If you've written logic important to your domain,
     there is nothing preventing you from being able to
     use that logic with other technology - nothing
     except coupling.
     - Michael Feathers
     - On his blog on January 2013
     

     View Slide

136. ACTIVE RECORD
     

     View Slide

137. ACTIVE RECORD
     GuILTY
     http://railsoopbook.com
     http://www.slideshare.net/pcalcado/from-a-monolithic-ruby-on-rails-app-to-the-jvm
     

     View Slide

138. “rails is not your app”
     what
     means is...
     

     View Slide

139. YOUR APP IS YOUR
     BUSINESS LOGIC
     

     View Slide

140. MAKE IT
     CONTEXT
     INDEPENDENT
     

     View Slide

141. MAKE IT
     DELIVERY
     INDEPENDENT
     

     View Slide

142. MAKE IT
     FRAMEWORK
     INDEPENDENT
     

     View Slide

143. wrapping up
     

     View Slide

144. what about productivity?
     

     View Slide

145. View Slide

146. http://www.threeriversinstitute.org/blog/?p=338
     In a connected system, elements are highly available to each other.
     Adding the first feature to a connected system is cheap. All the
     resources you need are available. However, the cost of all those
     connections is that subsequent features are very likely to interact
     with previous features, driving up the cost of development over time.
     

     View Slide

147. http://www.threeriversinstitute.org/blog/?p=338
     In a modular design connections are deliberately kept to a minimum.
     The cost for the first feature is likely to be higher than in the
     connected system, because you need to find the necessary resources
     and bring them together, possibly re-modularizing in the process.
     Features are much less likely to interact in a modular system, though,
     leading to a steady stream of features at relatively constant cost.
     

     View Slide

148. THE RAILS WAY
     IS A TRADEOFF
     

     View Slide

149. THE RAILS WAY
     IS A TRADEOFF
     a really big one!
     

     View Slide

150. finally...
     

     View Slide

151. - Not about anemic domain models
     - Nothing to do with J2EE
     - Also on @DHH’s list (ironically)
     - The rails way’s antithesis (IMHO)
     - Not about data centric approaches
     - Not on @DHH’s list (but it should)
     

     View Slide

152. RAILS VS CONTEXT INDEPENDENCE
     RAILS VS MODULAR DESIGN
     RAILS VS OOP
     

     View Slide

153. RAILS VS CONTEXT INDEPENDENCE
     RAILS VS MODULAR DESIGN
     RAILS VS OOP
     do not care about this
     

     View Slide

154. RAILS VS CONTEXT INDEPENDENCE
     RAILS VS MODULAR DESIGN
     RAILS VS OOP
     do not care about this
     

     View Slide

155. CONNECTED DESIGN
     VS
     MODULAR DESIGN
     

     View Slide

156. CONTEXT DEPENDENCE
     VS
     CONTEXT INDEPENDENCE
     

     View Slide

157. FRAMEWORKS ARE
     NOT WAYS OF LIFE
     JUST TOOLS
     http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html
     

     View Slide

158. now beer!
     thank you
     

     View Slide

159. Credits
     

     View Slide

160. Ruby Midwest 2011 Logo: http://cdn.confreaks.com/system/events/logos/49/rmw-logo-mid-original.png?1323836412
     Uncle Bob picture: http://www.flickr.com/photos/koss/3250213001/
     Home Alone Picture: http://www.multiplemayhemmamma.com/wp-content/uploads/2013/03/home-alone.jpg
     Terrified Adult Picture: http://sidoxia.files.wordpress.com/2011/02/scared.jpg
     Terrified Baby Picture: http://2.bp.blogspot.com/_0p-Jm7tsSa8/TNDUaU-HdHI/AAAAAAAAFfE/9ubR079H9UE/s1600/DSC_0425.JPG
     Spaghetti Picture: http://tonispilsburycom.wpengine.netdna-cdn.com/wp-content/uploads/2012/01/Mira10.jpg
     Dr. House Picture: http://4.bp.blogspot.com/-_EO0zOLq8YU/T8OUH5Zl5rI/AAAAAAAABLk/O_LYbtJuS1w/s1600/House+facepalm.jpg
     Martin Fowler Picture: http://www.flickr.com/photos/pragdave/173640462/
     Vaughn Vernon Picture: https://si0.twimg.com/profile_images/1670662520/VaughnVernon_2011_2.JPG
     Fat & Skinny Silhouette: http://2.bp.blogspot.com/-C_B_KLHbBJ4/TiMWn5L5xUI/AAAAAAAAEDs/lqwnKydRPiQ/s1600/transition-fat_to_thin1.jpg
     Bear Facepalm Picture: http://blog.littlebigfund.org/wp-content/uploads/2013/04/facepalm-wallpaper.jpg
     Lion Facepalm Picture: http://wolfallen.w.o.pic.centerblog.net/nqgyh2l0.jpg
     

     View Slide

161. Table Icon: http://fortawesome.github.io/Font-Awesome/icon/table/
     Robot: http://icons.iconarchive.com/icons/martin-berube/character/256/Robot-icon.png
     Monster: http://icons.iconarchive.com/icons/martin-berube/character/256/Monster-icon.png
     Database Icon: http://iconmonstr.com/database-icon/
     Buried In Paper Picture: http://everythingchangesbook.com/wp-content/uploads/2009/03/paper-pile.jpg
     Cave Picture: http://imagenes.viajeros.com/fotos/l/ll/lleimrlh-1259512525.jpg
     Globe Icon: http://iconmonstr.com/globe-4-icon/
     Refresh Icon: http://iconmonstr.com/refresh-2-icon/
     J.B. Rainsberger Avatar: http://www.devtraining.ee/sites/default/files/trainers/rainsberger_0.jpg
     Michael Feathers Avatar: http://i985.photobucket.com/albums/ae335/edepodesta/MichaelFeathersNew.jpg
     Kent Beck Picture: http://www.flickr.com/photos/26420411@N02/3062930943/
     Tool Icon: http://fortawesome.github.io/Font-Awesome/icon/wrench/
     

     View Slide