My domain is mine and I don't share it

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

once upon a time...

Slide 3

Slide 3 text

there was a keynote

Slide 4

Slide 4 text

ARCHITECTURE the lost years Robert Martin / Uncle Bob

Slide 5

Slide 5 text

ARCHITECTURE “WEB” IS NOT AN

Slide 6

Slide 6 text

IS DELIVERED “WEB” IS HOW YOUR APP

Slide 7

Slide 7 text

ARCHITECTURE FRAMEWORKS IS NOT ABOUT

Slide 8

Slide 8 text

ARCHITECTURE DEFERRING IS ABOUT DECISIONS

Slide 9

Slide 9 text

FRAMEWORKS A DETAIL ARE JUST

Slide 10

Slide 10 text

RAILS IS A DETAIL

Slide 11

Slide 11 text

RAILS IS NOT YOUR APP

Slide 12

Slide 12 text

RAILS IS NOT A WAY

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

wait a minute...

Slide 17

Slide 17 text

WTF DOES THAT EVEN MEAN ???????????????????????? ???????????????????????? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

Slide 18

Slide 18 text

let’s think it through

Slide 19

Slide 19 text

jacegu jacegu javieracero.com

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

PRESENTATION BUSINESS LOGIC DATA SOURCES 1 2 3

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

HOW OFTEN DO BUSINESS RULES CHANGE

Slide 30

Slide 30 text

HOW OFTEN DO DOMAIN RULES CHANGE

Slide 31

Slide 31 text

HOW OFTEN DO NAMING RULES CHANGE

Slide 32

Slide 32 text

IT’S ALL ABOUT CHANGE

Slide 33

Slide 33 text

BUSINESS is a DIFFERENT LOGIC KIND OF BEAST

Slide 34

Slide 34 text

???????????????????????? ???????????????????????? ? ? ? ? ? ? ? ? ? ? ? ? ? ? what’s business logic

Slide 35

Slide 35 text

IKIPEDI W A

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

LET’S ASK @DHH

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

CALCULATIONS VALIDATIONS CALLS TO OTHER SYSTEMS BUSINESS LOGIC

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

MORE PEAA

Slide 47

Slide 47 text

TRANSACTION SCRIPT

Slide 48

Slide 48 text

TRANSACTIONS business logic as

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

DIS 00 {duplicated code procedural code duplicated code procedural code duplicated code procedural code duplicated code procedural code ADVANTAGES

Slide 52

Slide 52 text

duplicated code gets worse as the application grows time

Slide 53

Slide 53 text

TABLE MODULE

Slide 54

Slide 54 text

OPERATIONS business logic as TABLE ROWS on

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

DOMAIN MODEL

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

OBJECT business logic as BEHAVIOUR

Slide 62

Slide 62 text

OBJECT GRAPHS modeled as Product Price Stock ProductService ProductRepository

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

The Object Oriented way of implementing business logic. ADVANTAGES

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

which one should I use? ???????????????????????? ???????????????????????? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

dude... get to the point!

Slide 71

Slide 71 text

HOW DOES “BUSINESS LOGIC ON RAILS” LOOK LIKE

Slide 72

Slide 72 text

probably a “domain model”

Slide 73

Slide 73 text

PROGRAMMING IS HARD

Slide 74

Slide 74 text

DESIGN IS EVEN HARDER

Slide 75

Slide 75 text

IMPLEMENTING A DOMAIN MODEL IS NOT EASY

Slide 76

Slide 76 text

antipatterns

Slide 77

Slide 77 text

ANEMIC DOMAIN MODEL

Slide 78

Slide 78 text

OBJECTS HAVE NO BEHAVIOUR

Slide 79

Slide 79 text

BUSINESS LOGIC IS SOMEWHERE ELSE

Slide 80

Slide 80 text

IN CONTROLLERS IN SERVICES so-called

Slide 81

Slide 81 text

J2EE WAY?

Slide 82

Slide 82 text

J2EE WAY? transaction script

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

Controller Model

Slide 85

Slide 85 text

Controller Model THE PIPE REFACTOR

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

DESIGN PATTERN “PUSH IT DOWN” IS NOT A

Slide 89

Slide 89 text

Controller Model

Slide 90

Slide 90 text

Controller Model

Slide 91

Slide 91 text

Controller Model look! a god object

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

No content

Slide 96

Slide 96 text

RUBY IS DYNAMIC IN NATURE

Slide 97

Slide 97 text

No content

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

CONCERNS ARE A TEXT EDITOR FEATURE

Slide 100

Slide 100 text

INHERITANCE MIXINS CONCERNS

Slide 101

Slide 101 text

MULTIPLE INHERITANCE MIXINS CONCERNS

Slide 102

Slide 102 text

INHERITANCE IS THE STRONGEST FORM OF COUPLING

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

TABLE DRIVEN DOMAIN MODEL

Slide 106

Slide 106 text

WHEN THE DOMAIN MODEL IS A DATA MODEL

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

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

Slide 109

Slide 109 text

ACTIVE RECORD

Slide 110

Slide 110 text

ACTIVE RECORD GuILTY http://railsoopbook.com

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

DATABASES A HARDWARE SOLVE PROBLEM

Slide 113

Slide 113 text

DATA SOURCES 3 databases belong in here

Slide 114

Slide 114 text

databases belong in here BUSINESS LOGIC 2 do not

Slide 115

Slide 115 text

CRUD OBSESSION the

Slide 116

Slide 116 text

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

Slide 117

Slide 117 text

Creates Deletes Reads Updates

Slide 118

Slide 118 text

Database Database Database Database

Slide 119

Slide 119 text

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

Slide 120

Slide 120 text

we are not digitalizing paper anymore

Slide 121

Slide 121 text

there is an app for that

Slide 122

Slide 122 text

DOMAIN MODEL CONNECTED

Slide 123

Slide 123 text

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

Slide 124

Slide 124 text

a. k. a. FRAMEWORK DOMAIN MODEL THE

Slide 125

Slide 125 text

a. k. a. CONNECTED DESIGN DOMAIN MODEL THE

Slide 126

Slide 126 text

a. k. a. ARCHITECTURELESS DOMAIN MODEL THE

Slide 127

Slide 127 text

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

Slide 128

Slide 128 text

NO LAYERING

Slide 129

Slide 129 text

NO SEPARATION OF PRESENTATION BUSINESS LOGIC DATA SOURCES 1 2 3

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

STATE GL BAL

Slide 132

Slide 132 text

business logic context it’s running in <>

Slide 133

Slide 133 text

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

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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

Slide 136

Slide 136 text

ACTIVE RECORD

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

YOUR APP IS YOUR BUSINESS LOGIC

Slide 140

Slide 140 text

MAKE IT CONTEXT INDEPENDENT

Slide 141

Slide 141 text

MAKE IT DELIVERY INDEPENDENT

Slide 142

Slide 142 text

MAKE IT FRAMEWORK INDEPENDENT

Slide 143

Slide 143 text

wrapping up

Slide 144

Slide 144 text

what about productivity?

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

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.

Slide 147

Slide 147 text

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.

Slide 148

Slide 148 text

THE RAILS WAY IS A TRADEOFF

Slide 149

Slide 149 text

THE RAILS WAY IS A TRADEOFF a really big one!

Slide 150

Slide 150 text

finally...

Slide 151

Slide 151 text

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

Slide 152

Slide 152 text

RAILS VS CONTEXT INDEPENDENCE RAILS VS MODULAR DESIGN RAILS VS OOP

Slide 153

Slide 153 text

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

Slide 154

Slide 154 text

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

Slide 155

Slide 155 text

CONNECTED DESIGN VS MODULAR DESIGN

Slide 156

Slide 156 text

CONTEXT DEPENDENCE VS CONTEXT INDEPENDENCE

Slide 157

Slide 157 text

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

Slide 158

Slide 158 text

now beer! thank you

Slide 159

Slide 159 text

Credits

Slide 160

Slide 160 text

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

Slide 161

Slide 161 text

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/