Pro Yearly is on sale from $80 to $50! »

My domain is mine and I don't share it

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.

607891bd2cfbfa3a75ada8e110992d47?s=128

Javier Acero

May 30, 2013
Tweet

Transcript

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

    share it !!
  2. once upon a time...

  3. there was a keynote

  4. ARCHITECTURE the lost years Robert Martin / Uncle Bob

  5. ARCHITECTURE “WEB” IS NOT AN

  6. IS DELIVERED “WEB” IS HOW YOUR APP

  7. ARCHITECTURE FRAMEWORKS IS NOT ABOUT

  8. ARCHITECTURE DEFERRING IS ABOUT DECISIONS

  9. FRAMEWORKS A DETAIL ARE JUST

  10. RAILS IS A DETAIL

  11. RAILS IS NOT YOUR APP

  12. RAILS IS NOT A WAY

  13. None
  14. None
  15. None
  16. wait a minute...

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

    ? ? ? ? ? ? ? ? ? ? ?
  18. let’s think it through

  19. jacegu jacegu javieracero.com

  20. None
  21. 1

  22. 3

  23. 2

  24. PRESENTATION BUSINESS LOGIC DATA SOURCES 1 2 3

  25. ARE THESE 3 LAYERS YOUR APP? ARE THEY EQUALLY IMPORTANT?

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

    DO THEY OBEY THE SAME RULES? DO THEY CHANGE AT THE SAME PACE?
  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?
  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?
  29. HOW OFTEN DO BUSINESS RULES CHANGE

  30. HOW OFTEN DO DOMAIN RULES CHANGE

  31. HOW OFTEN DO NAMING RULES CHANGE

  32. IT’S ALL ABOUT CHANGE

  33. BUSINESS is a DIFFERENT LOGIC KIND OF BEAST

  34. ???????????????????????? ???????????????????????? ? ? ? ? ? ? ? ?

    ? ? ? ? ? ? what’s business logic
  35. IKIPEDI W A

  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
  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
  38. LET’S ASK @DHH

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

  40. None
  41. None
  42. None
  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
  44. CALCULATIONS VALIDATIONS CALLS TO OTHER SYSTEMS BUSINESS LOGIC

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

    ? ? ? ? ? ? ? ? ? ? ? ? ? ?
  46. MORE PEAA

  47. TRANSACTION SCRIPT

  48. TRANSACTIONS business logic as

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

  50. simple easy to understand works great with simple datasources makes

    transaction boundaries visible 00 {ADVANTAGES
  51. DIS 00 {duplicated code procedural code duplicated code procedural code

    duplicated code procedural code duplicated code procedural code ADVANTAGES
  52. duplicated code gets worse as the application grows time

  53. TABLE MODULE

  54. OPERATIONS business logic as TABLE ROWS on

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

    & class RecordSet
  56. helps overcoming the relational - o.o. mismatch avoids duplication better

    than a transaction script 00 {ADVANTAGES
  57. 00 {modeling limited by and tied to the data model

    mechanisms basic to oop like polymorphism are not available DISADVANTAGES
  58. DOMAIN MODEL

  59. A software model based specifically in the domain of the

    business you are working with. - Vaughn Vernon - Implementing Domain Driven Design
  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
  61. OBJECT business logic as BEHAVIOUR

  62. OBJECT GRAPHS modeled as Product Price Stock ProductService ProductRepository

  63. The Object Oriented way of implementing business logic. - Martin

    Fowler - Patterns of Enterprise Application Architecture
  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.
  65. The Object Oriented way of implementing business logic. ADVANTAGES

  66. the hardest to comprehend data sources get more complex overhead

    for simple business logic DISADVANTAGES 00 {
  67. which one should I use? ???????????????????????? ???????????????????????? ? ? ?

    ? ? ? ? ? ? ? ? ? ? ?
  68. effort to enhance complexity of the business logic domain model

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

    model table module transaction script
  70. dude... get to the point!

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

  72. probably a “domain model”

  73. PROGRAMMING IS HARD

  74. DESIGN IS EVEN HARDER

  75. IMPLEMENTING A DOMAIN MODEL IS NOT EASY

  76. antipatterns

  77. ANEMIC DOMAIN MODEL

  78. OBJECTS HAVE NO BEHAVIOUR

  79. BUSINESS LOGIC IS SOMEWHERE ELSE

  80. IN CONTROLLERS IN SERVICES so-called

  81. J2EE WAY?

  82. J2EE WAY? transaction script

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

  84. Controller Model

  85. Controller Model THE PIPE REFACTOR

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

  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
  88. DESIGN PATTERN “PUSH IT DOWN” IS NOT A

  89. Controller Model

  90. Controller Model

  91. Controller Model look! a god object

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

    that! CONCERNS
  93. None
  94. None
  95. None
  96. RUBY IS DYNAMIC IN NATURE

  97. None
  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
  99. CONCERNS ARE A TEXT EDITOR FEATURE

  100. INHERITANCE MIXINS CONCERNS

  101. MULTIPLE INHERITANCE MIXINS CONCERNS

  102. INHERITANCE IS THE STRONGEST FORM OF COUPLING

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

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

  105. TABLE DRIVEN DOMAIN MODEL

  106. WHEN THE DOMAIN MODEL IS A DATA MODEL

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

    :Purchase
  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
  109. ACTIVE RECORD

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

  111. None
  112. DATABASES A HARDWARE SOLVE PROBLEM

  113. DATA SOURCES 3 databases belong in here

  114. databases belong in here BUSINESS LOGIC 2 do not

  115. CRUD OBSESSION the

  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
  117. Creates Deletes Reads Updates

  118. Database Database Database Database

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

    not use casesthemselves
  120. we are not digitalizing paper anymore

  121. there is an app for that

  122. DOMAIN MODEL CONNECTED

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

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

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

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

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

  128. NO LAYERING

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

    3
  130. None
  131. STATE GL BAL

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

  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
  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
  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
  136. ACTIVE RECORD

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

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

  139. YOUR APP IS YOUR BUSINESS LOGIC

  140. MAKE IT CONTEXT INDEPENDENT

  141. MAKE IT DELIVERY INDEPENDENT

  142. MAKE IT FRAMEWORK INDEPENDENT

  143. wrapping up

  144. what about productivity?

  145. None
  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.
  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.
  148. THE RAILS WAY IS A TRADEOFF

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

  150. finally...

  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)
  152. RAILS VS CONTEXT INDEPENDENCE RAILS VS MODULAR DESIGN RAILS VS

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

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

    OOP do not care about this
  155. CONNECTED DESIGN VS MODULAR DESIGN

  156. CONTEXT DEPENDENCE VS CONTEXT INDEPENDENCE

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

  158. now beer! thank you

  159. Credits

  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
  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/