The Curse of Service Object

Slide 1

Slide 1 text

The curse OF Service objects Ivan Nemytchenko wrocleve.rb 2024

Slide 2

Slide 2 text

Who am I painlessrails.com makefile.site UrbanConnect Setyl 🇬🇧 🇨🇭 Ivan Nemytchenko 🇷🇺→🇷🇸 Twitter: @inemation Github: @inem on Rails since 2006 Small agency owner ex GitLab

Slide 3

Slide 3 text

Who am I and why am I here

Slide 4

Slide 4 text

Service Object is • a very strange, controversial, and harmful abstraction* • that doesn’t make any sense • contradicts with main architecture principles • and doesn’t give you any benefits*

Slide 5

Slide 5 text

Slide 6

Slide 6 text

OOP In pictures

Slide 7

Slide 7 text

Kettle components (objects) small dudes == objects

Slide 8

Slide 8 text

Objects with methods! hands == methods

Slide 9

Slide 9 text

A method number of fi ngers == number of arguments

Slide 10

Slide 10 text

Instance variables Stored inside the brain

Slide 11

Slide 11 text

Instance variables Can be reused later

Slide 12

Slide 12 text

Returning results

Slide 13

Slide 13 text

Private methods

Slide 14

Slide 14 text

Exception

Slide 15

Slide 15 text

Anti-patterns

Slide 16

Slide 16 text

Too many arguments

Slide 17

Slide 17 text

Too many methods

Slide 18

Slide 18 text

Too long methods

Slide 19

Slide 19 text

Too many instance variables

Slide 20

Slide 20 text

Too much conditional logic in methods Swallen arms

Slide 21

Slide 21 text

Too much of everything!!!

Slide 22

Slide 22 text

Classes A spawning platform

Slide 23

Slide 23 text

Classes A spawning platform

Slide 24

Slide 24 text

same topology Object & classes have the

Slide 25

Slide 25 text

Visual representation of code complexity

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

WHAT is SERVICE OBJECT?

Slide 28

Slide 28 text

What do devs say?

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

What do devs say? • Maintainability, avoid code bloat • Single responsibility • More modular • Encapsulates business logic • Easier to test • Keeps your code clean, organized and structured

Slide 31

Slide 31 text

What do developers do?

Slide 32

Slide 32 text

Service Objects in the wild

Slide 33

Slide 33 text

Service Objects in the wild

Slide 34

Slide 34 text

Service Objects in the wild

Slide 35

Slide 35 text

Service Objects in the wild

Slide 36

Slide 36 text

Service Objects in the wild

Slide 37

Slide 37 text

Service Objects in the wild

Slide 38

Slide 38 text

Service Objects in the wild

Slide 39

Slide 39 text

What do we see? • Validation • Calculation • Creation of an entity (mutation) • Business scenario (mutation + notification) • Business scenario (external service + mutation) • Wrapper for external service

Slide 40

Slide 40 text

The Definition of service object They just do stuff

Slide 41

Slide 41 text

Is the a more deep, philosophical idea behind it?

Slide 42

Slide 42 text

What is so service about them?

Slide 43

Slide 43 text

fowler Patterns of Enterprise Application Architecture

Slide 44

Slide 44 text

Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic

Slide 45

Slide 45 text

Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary

Slide 46

Slide 46 text

Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations

Slide 47

Slide 47 text

Martin fowler Patterns of Enterprise Application Architecture Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Eric Evans Domain-Driven Design

Slide 54

Slide 54 text

Eric Evans Domain-Driven Design Domain Services: • are stateless

Slide 55

Slide 55 text

Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity

Slide 56

Slide 56 text

Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations

Slide 57

Slide 57 text

Eric Evans Domain-Driven Design Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Robert martin Clean Code

Slide 62

Slide 62 text

Robert martin Clean Code • service should have well-de fi ned interface

Slide 63

Slide 63 text

Robert martin Clean Code • service should have well-de fi ned interface • can be a single component or composed of several components

Slide 64

Slide 64 text

Robert martin Clean Code • service should have well-de fi ned interface • can be a single component or composed of several components separated by architectural boundaries •

Slide 65

Slide 65 text

Robert martin Clean Code • "service should have well-de fi ned interface” • can be a single component or composed of several components separated by architectural boundaries • Context: SOA and Microservices

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

The message being sent to us Domain Services: • are stateless • named for an activity rather than an entity • represent signi fi cant business domain processes/operations • are distinct from technical services • may have side effects Service layer: • separates domain logic from application logic • de fi nes application boundary • sets available operations • coordinates domain objects • controls transactions • encapsulates the app's business logic Single Responsibility Principle !

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Technical services == Application logic? Service Layer consists of Domain Services, which are: • are stateless • named for an activity rather than an entity • represent signi fi cant operations • coordinate domain objects & control transactions • comply with Single Responsibility principle • may have side effects The message being sent to us 🫷 🫸

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Our Service Ruler!! Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic 🫷 🫸

Slide 73

Slide 73 text

Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic

Slide 74

Slide 74 text

± Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic ?

Slide 75

Slide 75 text

? Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic

Slide 76

Slide 76 text

± ± Domain Service: is stateless named for an activity, not entity represents business operations coordinates domain objects controls transactions complies with Single Responsibility principle should theoretically have side effects no application logic

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

What do devs say? Maintainability, avoid code bloat Single responsibility More modular Encapsulates business logic Easier to test Keeps your code clean, organized and structured ? ± ?

Slide 83

Slide 83 text

What is so object about them?

Slide 84

Slide 84 text

Is there a reason why they are shaped like objects?

Slide 85

Slide 85 text

What is so object about them? • encapsulation • inheritance • polymorphism

Slide 86

Slide 86 text

What is so object about them? • encapsulation • inheritance • polymorphism ± 😱

Slide 87

Slide 87 text

What is so object about them? • state? • lifecycle of an object? • multiple instances of a class?

Slide 88

Slide 88 text

What is so object about them? • state? • lifecycle of an object? • multiple instances of a class?

Slide 89

Slide 89 text

What is so object about them? Pretty much nothing

Slide 90

Slide 90 text

What is service object? • It is a technical trick • In the sake of • moving code from controllers? • testing it separately? (±)

Slide 91

Slide 91 text

Serious guys are doing it too

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

No content

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

Calls another Service

Slide 96

Slide 96 text

BaseService CreateService

Slide 97

Slide 97 text

BaseService CreateService BaseServiceUtility

Slide 98

Slide 98 text

No content

Slide 99

Slide 99 text

Complexity Grows inward

Slide 100

Slide 100 text

What we see • Proactively stealing controller’s responsibilities • Mixing application logic with domain logic inside service objects

Slide 101

Slide 101 text

What we see • Code doing different types of work go in the same bucket. • Lots of low level code doing different types of work

Slide 102

Slide 102 text

What we see • Code doing different types of work go in the same bucket. • Lots of low level code doing different types of work

Slide 103

Slide 103 text

Validations Complex mutations Interaction with External systems Calculation logic Business rules Business operations Data preparation Caching Response preparation Work with session

Slide 104

Slide 104 text

What we see • Call chains of Services

Slide 105

Slide 105 text

What we see • Inheritance 😱

Slide 106

Slide 106 text

What we see • Over time complexity grows inward

Slide 107

Slide 107 text

What we see • Service Layer becomes responsible for everything • Effectively we have killed ideas of Layered Architecture, Modularity and SRP at this point.

Slide 108

Slide 108 text

The curse • No reason for services to be shaped as objects • Doesn’t match with what Fathers said • Devs do not achieve proclaimed benefits • Opposes ideas of Layered architecture, Modularity and SRP

Slide 109

Slide 109 text

Validations Complex mutations Interaction with External systems Calculation logic Business rules Business operations Data preparation Caching Response preparation Work with session

Slide 110

Slide 110 text

Mutators Business Rules Business Operations

Slide 111

Slide 111 text

Business Operations Mutators Business Rules

Slide 112

Slide 112 text

Business Operations Mutations Business Rules

Slide 113

Slide 113 text

Interaction with external systems Business Rules Business Operations Mutations

Slide 114

Slide 114 text

Business Rules Data preparation, validations Interaction with external systems Business Operations Mutations

Slide 115

Slide 115 text

Services Managers Mutators Business Rules Forms "Throughout our history, it has always been standardisation of components that has enabled creations of greater complexity" - Simon Wardley

Slide 116

Slide 116 text

how do I do it

Slide 117

Slide 117 text

how do I do it and how do I think about it

Slide 118

Slide 118 text

No content

Slide 119

Slide 119 text

• Long methods are fine • as long as it is the same type of work • and the same level of abstraction

Slide 120

Slide 120 text

No content

Slide 121

Slide 121 text

• Let’s have its own “shelf” for every type of work done by your app. • Some shelves we do have already

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

• Low level details of complex mutations go into its own Mutator layer • Mutators are just procedures • No need for callbacks • No more half-baked objects in your system anymore

Slide 124

Slide 124 text

No content

Slide 125

Slide 125 text

• Domain services are business operations • It is just a procedure • But of a high level of abstraction

Slide 126

Slide 126 text

No content

Slide 127

Slide 127 text

• Keep application logic outside of services • Check permissions outside of service • Only call it with valid params

Slide 128

Slide 128 text

No content

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

Slide 134

Slide 134 text

Modularity

Slide 135

Slide 135 text

LAYERed ARCHITECTURE

Slide 136

Slide 136 text

Single responsibility principle

Slide 137

Slide 137 text

EASIER to test

Slide 138

Slide 138 text

Services Mutators Models Controller actions

Slide 139

Slide 139 text

No content

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

No content

Slide 142

Slide 142 text

No content

Slide 143

Slide 143 text

No content

Slide 144

Slide 144 text

No content

Slide 145

Slide 145 text

Twitter: @inemation Github: @inem Do you still think Service Object was a good idea?