$30 off During Our Annual Pro Sale. View Details »

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.

Javier Acero

May 30, 2013
Tweet

More Decks by Javier Acero

Other Decks in Programming

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

    View Slide

  22. 3

    View Slide

  23. 2

    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