Slide 1
Slide 1 text
The SHAPE OF
A Service object
Ivan Nemytchenko
EuRuKo 2024
Slide 2
Slide 2 text
Who am I and why am I here
- Age: on Rails since 2006
- Current role: CTO at setyl.com
- Passion: Complexity organization optimization
- At my agency: RBBR Limited
- Methodology: “Painless Rails“
- My twittter: x.com/inemation
- My stuff: taplink.cc/inem
Slide 3
Slide 3 text
Service object is a De facto
standard
Standard building block for complexity management
Slide 4
Slide 4 text
Service object is a FAKE
concept
Slide 5
Slide 5 text
The shape
Slide 6
Slide 6 text
COde TOPOLOGY
notation
Slide 7
Slide 7 text
Objects
Slide 8
Slide 8 text
Objects with methods
Slide 9
Slide 9 text
A method with arguments
Slide 10
Slide 10 text
Instance variables
Slide 11
Slide 11 text
Instance variables
Slide 12
Slide 12 text
Returning results
Slide 13
Slide 13 text
Private methods
Slide 14
Slide 14 text
Classes
A spawning platform
Slide 15
Slide 15 text
Classes
A spawning platform
Slide 16
Slide 16 text
same topology
Object & classes have the
Slide 17
Slide 17 text
No content
Slide 18
Slide 18 text
The shape
Slide 19
Slide 19 text
Service Objects in the wild
Slide 20
Slide 20 text
Service Objects in the wild
Slide 21
Slide 21 text
Service Objects in the wild
Slide 22
Slide 22 text
Service Objects in the wild
Slide 23
Slide 23 text
Service Objects in the wild
Slide 24
Slide 24 text
Service Objects in the wild
Slide 25
Slide 25 text
Service Objects in the wild
Slide 26
Slide 26 text
The Definition of service object
They just do stuff
Slide 27
Slide 27 text
The Definition of service object
They just do stuff
and they all look the same
Slide 28
Slide 28 text
The shape of A service object
Slide 29
Slide 29 text
Serious guys are doing it too
Slide 30
Slide 30 text
The shape of A service object
Slide 31
Slide 31 text
The shape of A service object
Slide 32
Slide 32 text
Complexity Grows inward
Slide 33
Slide 33 text
No content
Slide 34
Slide 34 text
Painless RAILS
1. Layered Architecture
2. Abstractions of a Single Level
3. Building blocks per type of work done by code
Slide 35
Slide 35 text
Splitting code
by the types of work
done by IT
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
No content
Slide 38
Slide 38 text
No content
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
No content
Slide 42
Slide 42 text
Let’s find its own “shelf”
for Every type of work
Slide 43
Slide 43 text
No content
Slide 44
Slide 44 text
account_locked?
fi
rst_login_from_new_ip?
User
Slide 45
Slide 45 text
No content
Slide 46
Slide 46 text
UserMutator
record_login_fact
handle_failed_login
Slide 47
Slide 47 text
No content
Slide 48
Slide 48 text
AuthController
create
Slide 49
Slide 49 text
No content
Slide 50
Slide 50 text
UserService
authenticate
Slide 51
Slide 51 text
No content
Slide 52
Slide 52 text
User User
AuthenticationService UserMutator
AuthController AuthController
UserService
Slide 53
Slide 53 text
No content
Slide 54
Slide 54 text
EASIER to test
Slide 55
Slide 55 text
Modularity
Slide 56
Slide 56 text
LAYERed ARCHITECTURE
Slide 57
Slide 57 text
Services
Mutators
Models
Controller actions
LAYERed ARCHITECTURE
Slide 58
Slide 58 text
Wait, they still could
be service objects!
Slide 59
Slide 59 text
No content
Slide 60
Slide 60 text
No content
Slide 61
Slide 61 text
No content
Slide 62
Slide 62 text
UserAuthenticationService
LoginEventRecorder
FailedLoginHandler
UserBusinessRules
UserMutator
UserService
User
+ service objects
TYPES OF WORK
Slide 63
Slide 63 text
UserAuthenticationService
LoginEventRecorder
FailedLoginHandler
UserBusinessRules
UserMutator
UserService
User
+ service objects
TYPES OF WORK
Slide 64
Slide 64 text
Services
Managers
Mutators
Business Rules
Forms
Building blocks per TYPES OF WORK
Slide 65
Slide 65 text
Services
Mutators
Models
Controller actions
LAYERed ARCHITECTURE
Slide 66
Slide 66 text
The SHAPE
AND THE MISSING IDEA
OF A Service object
Slide 67
Slide 67 text
Service object === shape
Slide 68
Slide 68 text
Service object is an empty
concept
Slide 69
Slide 69 text
Services
Mutators
Models
Controller actions
Service Objects
LAYERed ARCHITECTURE
Slide 70
Slide 70 text
FowLER & Evans
Slide 71
Slide 71 text
FowLER & Evans
Service Layer
Domain Services
Slide 72
Slide 72 text
fowler
Patterns of Enterprise Application
Architecture
Slide 73
Slide 73 text
Martin fowler
Patterns of Enterprise Application Architecture
Service layer:
• separates domain logic from
application logic
Slide 74
Slide 74 text
Martin fowler
Patterns of Enterprise Application Architecture
Service layer:
• separates domain logic from
application logic
• de
fi
nes application boundary
Slide 75
Slide 75 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 76
Slide 76 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 77
Slide 77 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
• controls transactions
Slide 78
Slide 78 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
• controls transactions
• encapsulates the app's business
logic
Slide 79
Slide 79 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
• controls transactions
• encapsulates the app's business logic
• coordinates responses
Slide 80
Slide 80 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
• controls transactions
• encapsulates the app's business logic
• coordinates responses
Slide 81
Slide 81 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
• controls transactions
• encapsulates the app's business logic
• coordinates responses
Slide 82
Slide 82 text
Eric Evans
Domain-Driven Design
Slide 83
Slide 83 text
Eric Evans
Domain-Driven Design
Domain Services:
• are stateless
Slide 84
Slide 84 text
Eric Evans
Domain-Driven Design
Domain Services:
• are stateless
• named for an activity rather than
an entity
Slide 85
Slide 85 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 86
Slide 86 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 87
Slide 87 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 88
Slide 88 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
• may have side effects
Slide 89
Slide 89 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
Slide 90
Slide 90 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
🤔
Slide 91
Slide 91 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
• may have side effects
The message being sent to us
🤔
Slide 92
Slide 92 text
The message being sent to us
is stateless
named for an activity, not entity
represents business operations
coordinates domain objects
controls transactions
should theoretically have side effects
no application logic
Domain Service:
Slide 93
Slide 93 text
The message being sent to us
Domain Service:
is stateless
named for an activity, not entity
represents business operations
coordinates domain objects
controls transactions
should theoretically have side effects
no application logic
Slide 94
Slide 94 text
Fowler-Evans Service Ruler!!
Domain Service:
is stateless
named for an activity, not entity
represents business operations
coordinates domain objects
controls transactions
should theoretically have side effects
no application logic
Slide 95
Slide 95 text
Recommendations
• Don’t use the term Service Object
• Don’t use Service Objects
• Split your code by the types of work done by it
• Types of work → Types of building blocks
• Measure your services with Fowler-Evans ruler!
Slide 96
Slide 96 text
https://Rails.services
Ivan Nemytchenko
EuRuKo 2024